윈도에 깔린 다른 subversion을 체크하기 위해서 Repository를 update해봤는데, 역시나 망할놈의 오류가 뜬다. (이런건 이제 감흥도 없다.)
# svn co https://(server_addr)/svn/Proj
인증 영역(realm): <https://(server_addr):443> Subversion Repositories
'elenoa'의 암호:
.....
svn: REPORT of '/svn/Proj/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://10.10.10.10)
#
'Could not read chunk size: Secure connection truncated' 요 에러를 찾아보려 했는데, 무슨 Apache의 Timeout을 조절해야 한다는둥, 무슨 파일이 너무 커서 그렇다는 둥, 뭔가 이야기들이 많다. 대충 알고 보니 그저 일반적인 오류일 뿐이다. 서버에서 연결을 끊었다거나, 어쨌든 서버의 예기치 않은 문제. (소켓에서 말하는 Connection Timeout 같은것인듯) 그래서 이쪽은 패스.
일단 Repository가 뭔가 이상한가 확인해보려고 svnadmin recover를 열심히 쳤다. 그래도 소용 없다. svn쪽 로그를 확인하려 했더니, 윈도의 이벤트 로거가 맛이 간 상태.
그러다가 어디에선가 svnsync로 백업하고, 거기에서 로그를 확인하는 방법을 제안했다. 이것도 좋다. 이것은 따로 잡아놓진 못했는데, rev 200까지 열심히 올라가다가 rev 201을 sync하지 못하고 오류를 내뿜는다. (뭔 CRC가 틀리다나?) 그래서 원 저장소의 (Repository)/db/revs/0/201 파일을 확인. 파일은 정상인듯 한데.
그러니까 svnadmin recover 명령은 bdb에서만 동작한다는거다. 이놈의 bdb가 워낙 자주 망가져서 fsfs가 개발된 이후 거의 쓰이지 않는다. 요놈은 fsfs의 무결성을 검사해서 복구해주는 스크립트인가보다. 그건 좋은데, 문제는 (Repository)/db/revs/0/201 파일이 더 이상 읽어지지 않는다는거다. (젠장!) 물리 디스크의 손상인갑지. 조금이라도 읽어질때 백업을 떠 놓을걸. 하지만 차 떠난 뒤에 손 흔들어 봤자 소용 없는 일이고.
복구를 하자. 201 파일을 지우고 빈 파일을 만들었는데 fsfsverify도 실패, 대충 그럴싸한 내용을 넣어봐도 실패. 이건 offset이라던가 뭔가 수치가 살짝 안맞는 경우에만 잘 동작하나보다. 이렇게 파일 하나가 왕창 깨진 이후에는 쓸모가 없는 놈인듯. 하는 수 없지.
정상적인 1부터 200 리비전까지 svnadmin dump 로 백업. Proj_BACKUP repos에 이 백업 내용을 업로드. 다행히 201 리비전은 binary 파일 4개가 신규로 업로드 된 것. 그래서 손상된 201 리비전을 커밋했던 사람을 찾아 해당 리비전에 커밋했던 파일 리스트(이건 커맨드라인에서 볼 수 있는 방법을 도저히 모르겠어서 TortoriseSVN에서 리스트를 확인) 를 넘겨주고, Proj_BACKUP repos에 커밋을 부탁함. 그 이후, Proj_BACKUP에서 생성된 db/revs/0/201 파일을 Proj repos에 다시 복사.
.. 될 리가 있나. 파일 크기는 같게 생성되었는데, 뭔가 메타데이터가 다른게 들어간듯. fsfsverify를 해봐야 소용없다. (아니, revision이 228밖에 안되는데 fsfsverify가 읽다가 오류를 낸다. 너무 항목이 많다나 뭐라나;)
그냥 201 리비전으로 롤백하고, 프로젝트 전원에게 201 리비전 이후에 업데이트된 내역과 함께 메일을 날려 알아서 커밋하라고 통보. case closed. (...)
