화일동기화

• Home-W - 집. 윈도2000
• Home-L - 집. 리눅스
• Lab-W - 연구실. 윈도XP
• Home-W 와 Lab-W 의 내문서 폴더(양쪽 다 D:\Work)를 동기화하고자 함. 북마크도 마찬가지로 할 수 있음
• 웬만하면 SSH 를 써서 좀 더 보안에 신경쓰고 싶음. Home-L 에 openssh 서버가 설치되어 있다. 윈도우즈용 ssh 서버로 적당한 것을 찾지 못한 상태 (상용을 사자니 돈이 아깝고, 윈도우즈에서 돌아가는 openssh 서버는 뭐가 있는지 모름)

1. Subversion을 사용

• Home-L 에 저장소를 만든다.
• Home-W 에서 D:\Work 를 import (TortoiseSVN 사용)
• Home-W 에서 D:\Work 를 삭제
• Home-W 에서 checkout 하여 D:\Work working copy 를 생성
• Lab-W 에서 checkout 하여 마찬가지로 D:\Work 를 생성
• 이후, Home-W 와 Lab-W 에서 commit, update 를 하여 일관성을 유지할 수 있다. 윈도우 머신에서는 TortoiseSVN 을 사용.

• 화일을 수정할 때, 수정하기 전의 버전이 자동으로 보관되므로 언제든지 되돌릴 수 있다.
• commit 하는 것을 잊은 채로 update 를 하거나, update 를 잊은 채로 commit 을 하려 할 때 merge 나 에러 등의 적절한 조치가 취해진다.
• 리눅스의 subversion 과 윈도우의 TortoiseSVN 둘 다 상당히 안정적으로 동작해서 좋다.

• .svn 디렉토리에 원본이 보관되므로 폴더의 크기가 2배 이상 커진다. (1.3GB 에서 2.6GB 가 되었음)
• 내문서 폴더에 화일이 추가, 삭제 될 때 별도로 svn 도 add, delete 도 해 주어야 한다.
• 거의가 hwp, doc, pdf 등의 바이너리 화일이므로, 어차피 merge 등을 할 수 없고, 굳이 예전 버전을 보관해야 될 이유가 그다지 크지 않기 때문에, 말 그대로 닭 잡는 데 소 잡는 칼을 쓰는 셈

• 기능상 제일 훌륭한 듯
• update 를 할 때 시간이 꽤 걸린다.

2. Rsync를 사용

• Home-W 에서 rsync 를 사용하여 Home-L 로 복사
• Home-L 에서 rsync 를 사용하여 Lab-W 로 복사
• 이후, 변경이 있을 경우 해당 PC 에서 Home-L 로 복사하고 (일종의 commit), Home-L 에서 다른 PC 로 복사한다 (일종의 update). 주인장의 경우, 집에서 나갈 때 Home-W 에서 commit 을 해주고, 연구실에 도착하면 제일 먼저 update 를 해 주는 식으로 했다.
• (Home-L 은 관여하지 않고, Home-W 와 Lab-W 사이에서 주고 받게 할 수도 있겠다.)

• 아래의 Unison을 사용하는 경우에 비해 체감속도가 빠르다.

• 일단, 매일 컴퓨터 앞에 처음 앉을 때와 마지막으로 일어설 때 꼬박꼬박 rsync 를 챙겨 주는 것이 귀찮은 일이다.
• 더 큰 문제는, update 하지 않고 commit, 또는 commit 하지 않고 update 했다가는 큰 낭패를 볼 수 있다는 점이다. 예를 들어 Home-A 에서 화일을 수정했는데, 이것을 commit 하는 과정을 잊은 채로 update 를 하면 Home-L 에 있던 화일로 복구(?)되어 버린다. 수정한 것을 그대로 날려버림.
• 윈도우에서 돌아가는 rsync 바이너리가 없어서, Cygwin 등을 사용해야 한다.
• 화일이 매우 많은 경우, 윈도우에서 rsync 가 제대로 종료되지 않는 모습을 보인다.

• 동기화나 백업에 관한 여러 문서에서 rsync 를 사용한 방법이 나와 있는데, 일방적으로 백업하는 경우라면 모를까, 양쪽에서 수정하고 서로 반영시켜야 하는 경우에는 위 단점에서 말한 문제점 때문에 위험부담이 너무 크다.
• 며칠 사용하다 결국 포기

3. Unison을 사용

• Home-W 와 Home-L 의 Work 폴더를 unison 으로 동기화
• Home-L 과 Lab-W 의 Work 폴더를 unison 으로 동기화
• (역시 Home-W 와 Lab-W 사이를 직접 동기화시킬 수도 있으나, 그러기 위해서는 어느 한 쪽에 ssh 서버가 있거나, 아니면 보안을 포기하고 unison 을 서버로 실행해서 직접 통신을 시킬 수 있다)

• 양쪽 머신의 디렉토리를 비교해서 변경 사항이 생길 경우 각 화일에 대해 일일이 사용자에게 물어본다. 따라서 Rsync를 썼을 때 처럼 '옛 버전이 새 버전을 덮어써 버리는' 불행한 사태를 막을 수 있다.
• gtk 를 사용한 GUI 인터페이스를 제공 (그렇지만 명령 프롬프트 창을 열어서 텍스트 커맨드로 처리하는 게 더 편하다)
• 동기화할 디렉토리와 설정값을 프로필이라는 명칭의 텍스트 화일로 저장할 수 있다. 따라서 한번만 설정을 해 주면 그 다음부터는 명령 프롬프트 창에서 "unison Work" "unison Favorites" 등과 같이 프로필 이름만 인자로 주면 된다. 굿~

• 양쪽 폴더를 점검하는 것만도 꽤 체감 시간이 길다. Subversion 에서 update 하는 시간보다 더 긴 듯.
• GUI 버전의 경우 한글이 제대로 표시되지 않는다. (도스창에서 텍스트 버전을 쓰면 별 문제는 없다)
• rsync 보다는 낫지만, 역시 꼬박꼬박 싱크를 해 주지 않았다면 어느 순간 어느 쪽이 더 최신 버전인지 헷갈린다. 화일 수정 시각을 보고 비교를 할 수는 있지만, 명백하게 revision 번호로 나타나는 Subversion 에 비해 불안하다.

• 이 글을 작성하기 한시간 쯤 전부터 사용해 보고 있음. 며칠 지내 볼 예정
• 이 방법마저 못마땅하다고 판단되면, 좀 거창하긴 하더라도 Subversion을 사용할 생각.

4. SmartSyncPro 를 사용

• 쉬운 인터페이스

• 이건 smart sync pro 의 단점은 아닌데.. 제일 처음 폴더를 동기화할 때는 모든 화일을 묶어서 하나의 화일을 생성하기 때문에, 상대방 PC 쪽에 1GB 짜리 화일을 전송해야 했다. 그런데 계속 도중에 FTP 접속이 끊기는 바람에, 결국 테스트만 성공하고 정작 Work 폴더는 동기화하는 데에 실패
• 이것도 그다지 큰 단점은 아니겠지만.. 어떤 화일을 수정할 경우, 반드시 수정한 쪽에서 commit 에 해당하는 동작을 해 주어서 변경내역 화일을 생성해 주어야 상대방 쪽에서 동기화를 할 수 있다. (rsync 나 unison 같은 경우는 수정한 쪽이 아니라 다른 쪽에서만 명령을 수행해 주어도 된다)
• FTP 서버가 있어야 한다.
• SSH 를 지원하지 않는다.

• 상용이긴 하지만, 살 가치가 충분히 있다고 생각됨. 리눅스나 유닉스 없이 윈도우즈 PC 들만 있는 경우 꽤 편하게 쓸 수 있을 듯.

5. 현재는

6. 의견란

CVS도 바이너리 파일의 첫 버전을 다시 보관하지 않던가요? 용량 문제에서는 다를 바가 없을 것 같은데요.

-- Raymundo 2004-8-26 1:30 pm

Subversion의 경우에는 local에 원본이 보관되므로 Home-W, Lab-W에 두 배의 저장공간이 필요한데 비해, CVS에서는 binary파일에 대해 server에서 diff 저장이 지원되지 않으므로, Home-L쪽에만 binary공간의 크기가 커질거라고 생각이 드는데요. Binary가 자주 update되면 이것도 문제긴 하겠네요.
네트웍 전송 속도가 안 좋은 상황에서는 subversion이 좋긴한데 말이죠.

-- 222.106.68.142 2004-8-26 2:16 pm

아 그러고보니... CVS는 서버 쪽에서만 보관을 했었죠. 근데 어쨌거나 굳이 버전 관리까지 (있으면야 좋겠지만) 필요한 정도는 아니다 싶고, Unison으로 충분히 만족스럽습니다. :-)

-- Raymundo 2004-8-26 5:12 pm