저는 출장 작업이 많아지면서 git/svk 등의 분산형으로 전환을 진지하게 생각하고 있습니다. (생각만 한지가 1, 2년 된것 같습니다.)
그런데, branch/merge도 때로는 골치아플때가 있는데, 저장소마저 분산이 되어버린다면, 일이 더 커질듯한데... 상상이 가지 않는 측면이 있습니다. 제가 버젼관리툴에 경험이 미천해서인지.... 새로운 툴의 도입/교육의 부하와 함께 분산형 도입을 망설이는 이유중 하나. 생각보다 간단할지도 모르겠지만...
그러나 과연 중앙집중식(?)이 유리한 점이 있을까요? update/commit 이란 단순 개념이 약간 확대되면서 골치아픈 일이 생길 수 있지만, 이것은 '분산형'을 쓰기위해선 피할 수 없는일이니 논외로 해야겠죠.
그런데 "운영에 따라 분산형이 중앙집중형을 충분히 대체..." 라고 하셨는데, 예를 들면 어떤 운영 방식인지가 궁금합니다.
저같은 경우엔 출장갈때 repository 덤프해서 서버를 들고다니는 짓까지 해봤는데요;;; 저혼자 작업할때야 상관없지만, 출장중에 회사에서 작업이 많이 진척될때는... 손이 고생하죠. 일명 '손'분산형 svn;;;
tortoiseSVN같은 git client가 있다면, 생각해봐야겠습니다.
덧. 최근 관련 토론에서 svk나 git를 사용해서 svn 서버의 분산 repository를 만들 수 있다는 말을 언듯 들었는데 솔깃하네요.
저도 GUI 좋아합니다. 그리고 현재 분산형 GUI client가 아직 중앙집중형에 비하여 약하다는 것도 알고 있고요.
제가 운영에 따라 분산형이 중앙집중형을 대체한다고 말한 것은 분산형도 최상위 저장소가 있어야 한다는 이야기죠. Project 운영을 대외적으로 공개하기 위한 server가 있어야 되지 않겠어요.
update/commit에 push/pull를 해야해서 한번 더 명령을 내려야 한다는 것은 좀 귀찮은 문제일 수도 있겠습니다. 하지만 이것도 client 설정을 통해 충분히 극복가능하죠. 사실 push/pull하고 나면 network에 연결되어 있을 필요가 없이 update/commit을 자신의 저장소에서 자유롭게 가능하다는 것이 분산형의 큰 장점이지만 말이예요.
가장 크게 어필하고 있는것은 로컬커밋의 저징이죠.
리팩토링을 하든 코드 수정을 하든
작게 수정하고 자주 수정하라는 황금율를 지키면서
서브버전을 쓰기에는 비용이 너무나 크죠.
(수정 중간중간 부분수정을 커밋하기도 좀 그렇고...)
제가 말하는 비용은 머지로 해결하는 리비전 복잡성의
문제뿐만 아니라, 커밋비용에 대한 문제를 포함합니다.
각기 여러 장단점이 있기는 한데, 중앙집중형이 유리한 점은 바이너리 파일 커밋이 많은 경우입니다. 분산형으로 하다 보면 저장소 크기가 감당할 수 없을만큼 커지기 쉽습니다. 반면 중앙집중형에서 체크아웃받은 소스는 최근의 바이너리 파일만 있어서 클라이언트 저장소 사이즈가 어느 정도 선에서 유지됩니다.
'Everything looks different on the other side.' -Ian Malcomm
'Everything looks different on the other side.' -Ian Malcomm
위에 "중앙 저장소라는 개념이 있기 때문에 최상위 리비전이 무엇인가 쉽게 알 수 있죠." 이란 말을 잘 이해 못하시는 듯 하네요. 좀 사용해본 사람이라면 이해하리라 보는데요. (순간적 혹은 오랫동안) 중앙 저장소가 꼭 최상위가 아닐 수가 있다는 말입니다
또, 각기 동일한 브랜치에서 분기해서 작업후 커밋이후 로컬에서 브랜치하여 계속 작업하면 커밋하면 중앙에서 동일 브랜치라고 생각지 못하는 경우가 생길 수도 있습니다. (그림으로는 설명이 쉬운데, 말로는 좀 어렵네요). 즉, B,C가 branch A에서 각각 작업하고, B가 중앙으로 커밋(A의 새로운 팁) 후 브랜치 만들어서 계속 작업했다면(더이상 A의 새로운 팁 아닌 것으로 보임), C가 커밋하는 시점에서 사실은 최초 B가 커밋한 changeset과 머지해야 하는데, 그 사실을 알기가 힘듭니다.
중앙 저장소라는
중앙 저장소라는 개념이 있기 때문에 최상위 리비전이 무엇인가 쉽게 알 수 있죠.
---- 절취선 ----
http://blog.peremen.name
분산형도 중앙 저장소를 둘 수 있지 않습니까?
운영에 따라 분산형이 중앙집중형을 충분히 대체할 수 있는 것 같아서 묻는 것입니다.
저는 출장 작업이
저는 출장 작업이 많아지면서 git/svk 등의 분산형으로 전환을 진지하게 생각하고 있습니다. (생각만 한지가 1, 2년 된것 같습니다.)
그런데, branch/merge도 때로는 골치아플때가 있는데, 저장소마저 분산이 되어버린다면, 일이 더 커질듯한데... 상상이 가지 않는 측면이 있습니다. 제가 버젼관리툴에 경험이 미천해서인지.... 새로운 툴의 도입/교육의 부하와 함께 분산형 도입을 망설이는 이유중 하나. 생각보다 간단할지도 모르겠지만...
그러나 과연 중앙집중식(?)이 유리한 점이 있을까요? update/commit 이란 단순 개념이 약간 확대되면서 골치아픈 일이 생길 수 있지만, 이것은 '분산형'을 쓰기위해선 피할 수 없는일이니 논외로 해야겠죠.
그런데 "운영에 따라 분산형이 중앙집중형을 충분히 대체..." 라고 하셨는데, 예를 들면 어떤 운영 방식인지가 궁금합니다.
저같은 경우엔 출장갈때 repository 덤프해서 서버를 들고다니는 짓까지 해봤는데요;;; 저혼자 작업할때야 상관없지만, 출장중에 회사에서 작업이 많이 진척될때는... 손이 고생하죠. 일명 '손'분산형 svn;;;
tortoiseSVN같은 git client가 있다면, 생각해봐야겠습니다.
덧. 최근 관련 토론에서 svk나 git를 사용해서 svn 서버의 분산 repository를 만들 수 있다는 말을 언듯 들었는데 솔깃하네요.
--
Life is short. damn short...
--
Life is short. damn short...
tortoiseGit가
tortoiseGit가 있더군요.. ^^;
완성도도
완성도도 tortoiseSVN정도 되는지 궁금하네요? (지금 시점에 그건 무리인가요? ^^) 한번 알아봐야겠네요...
--
Life is short. damn short...
--
Life is short. damn short...
tortoisehg는
거북이svn에 비해 떨어지는 걸 별로 못느낍니다.
모든것은 모든것에 잇닿아 있다.
------------------------------
모든것은 모든것에 잇닿아 있다.
맘에 안 드는 점
용량이 너무 크다. 봐줄 수는 있지만...
GUI push/pull 이 익숙하지 않아서인지 모르지만 이상하게 동작하는 것 같더군요. 제가 잘못 사용하고 있을 것 같긴 합니다만... 그래서 거북이 설치해놓고, CLI로 썼더라는... -_-.
Client program이 크게 문제가 되지는 않을 것 같습니다.
저도 GUI 좋아합니다. 그리고 현재 분산형 GUI client가 아직 중앙집중형에 비하여 약하다는 것도 알고 있고요.
제가 운영에 따라 분산형이 중앙집중형을 대체한다고 말한 것은 분산형도 최상위 저장소가 있어야 한다는 이야기죠. Project 운영을 대외적으로 공개하기 위한 server가 있어야 되지 않겠어요.
update/commit에 push/pull를 해야해서 한번 더 명령을 내려야 한다는 것은 좀 귀찮은 문제일 수도 있겠습니다. 하지만 이것도 client 설정을 통해 충분히 극복가능하죠. 사실 push/pull하고 나면 network에 연결되어 있을 필요가 없이 update/commit을 자신의 저장소에서 자유롭게 가능하다는 것이 분산형의 큰 장점이지만 말이예요.
"중앙집중형에
"중앙집중형에 운영의 묘를 곁들인다면, 굳이 분산형까지 필요 있겠냐" 라는 의미로 토론을 시작하신줄 알았네요.;;; 휴일에 근무하니 제가 정신이 없네여;;
--
Life is short. damn short...
--
Life is short. damn short...
분산형이 우월한 것중
가장 크게 어필하고 있는것은 로컬커밋의 저징이죠.
리팩토링을 하든 코드 수정을 하든
작게 수정하고 자주 수정하라는 황금율를 지키면서
서브버전을 쓰기에는 비용이 너무나 크죠.
(수정 중간중간 부분수정을 커밋하기도 좀 그렇고...)
제가 말하는 비용은 머지로 해결하는 리비전 복잡성의
문제뿐만 아니라, 커밋비용에 대한 문제를 포함합니다.
------------------------------
모든것은 모든것에 잇닿아 있다.
------------------------------
모든것은 모든것에 잇닿아 있다.
각기 여러 장단점이
각기 여러 장단점이 있기는 한데, 중앙집중형이 유리한 점은 바이너리 파일 커밋이 많은 경우입니다. 분산형으로 하다 보면 저장소 크기가 감당할 수 없을만큼 커지기 쉽습니다. 반면 중앙집중형에서 체크아웃받은 소스는 최근의 바이너리 파일만 있어서 클라이언트 저장소 사이즈가 어느 정도 선에서 유지됩니다.
'Everything looks different on the other side.' -Ian Malcomm
'Everything looks different on the other side.' -Ian Malcomm
위에 "중앙
위에 "중앙 저장소라는 개념이 있기 때문에 최상위 리비전이 무엇인가 쉽게 알 수 있죠." 이란 말을 잘 이해 못하시는 듯 하네요. 좀 사용해본 사람이라면 이해하리라 보는데요. (순간적 혹은 오랫동안) 중앙 저장소가 꼭 최상위가 아닐 수가 있다는 말입니다
또, 각기 동일한 브랜치에서 분기해서 작업후 커밋이후 로컬에서 브랜치하여 계속 작업하면 커밋하면 중앙에서 동일 브랜치라고 생각지 못하는 경우가 생길 수도 있습니다. (그림으로는 설명이 쉬운데, 말로는 좀 어렵네요). 즉, B,C가 branch A에서 각각 작업하고, B가 중앙으로 커밋(A의 새로운 팁) 후 브랜치 만들어서 계속 작업했다면(더이상 A의 새로운 팁 아닌 것으로 보임), C가 커밋하는 시점에서 사실은 최초 B가 커밋한 changeset과 머지해야 하는데, 그 사실을 알기가 힘듭니다.
그런 것들이 적어도 CVS 등에서는 일어나지 않는 현상이죠.