혹시 회사에서 머큐리얼 쓰시는 분 계신가요?

[김정훈]

회사에서 원래 SVN을 사용하다가 전사적으로 머큐리얼로 바뀐게 한 6-7개월정도 됩니다.

SVN 쓰려다가 머큐리얼 쓰려니까 참 불편하더군요. commit 한번 하면 끝나는 일을 commit 하고 push하고..

또 commit 하기전에 pull을 안하면 confilct 가 자주 발생하기 떄문에 pull-commit-push 세가지 작업을 동시에 해줘야 합니다.

물론 svn에 때도 update-commit 이렇게는 했지요.

클라이언트는 tortoisehg와 이클립스에 플러그인 형태로 쓰는데 속도가 svn때보다 느립니다. 또 머지는 왜이리 못하는지 툭하면 confilct발생되구요.

처음에는 내가 뭘 잘 몰라서 그런거겠지 하고 이것저것 인터넷으로 알아보기도 하고 일단은 쭉 사용해보고 있었는데 불편한점이 한두가지가 아니네요.

지금도 50메가 정도 되는 동영상 commit 하고 push하려 했더니 먹통이네요. 솔직히 SVN을 사용할 때에 비해서 뭐가 좋은지 전혀 모르겠습니다.

혹시 회사에서 머큐리얼 사용하시는 분들 중에 저와 같은 경우는 없는지 궁금하네요.

아님 제가 뭘 잘못하고 있는건지..답답하네요.

[CHAE.SW]

우선, 회사에서 현재 머큐리얼을 쓰고 있지는 않습니다.

예전에 몇 몇 분들과 함께 썼었는데요, 정훈님과 비슷하게 불편해 하시는 분들이 계셨습니다.

DVCS계열(git, mercurial)은 로컬 저장소에서 최대한 많은 일을 한 다음에 중앙저장소, 혹은 다른 저장소로 밀어넣는다(push한다)는 개념이기때문에 기존 SVN사용하듯이 매번 중앙서버로 밀어 넣으시는 형태라면 쓰신바와 같이 더 불편하고 단계만 늘은 것 처럼 느껴집니다. 뭐, 실제로도 그렇고요.

DVCS는 

우선 어느정도 개발은 했지만, 

중앙서버로 밀어넣기엔 부족한 경우,

즉, 서버의 빌드환경을 깨뜨릴것 같거나, 테스트 코드가 현재 깨지고 있거나, 버그가 있을것 같거나 같은 경우에도 저장소(보통 이때는 로컬저장소가 되겠죠)로 커밋해서 단계별로 관리 할 수 있다는 것이 장점이라는 걸 이해하셔야 합니다.

서브버전 사용자를 위한 머큐리얼(mercurial)이전 가이드

http://blog.doortts.com/141

를 한번 보시는것도 도움이 되실것 같습니다. 

:D

ps. 

이제와서 그만두면 지는거임.

2011/10/17 김정훈 <won...@gmail.com>

[Dajinsol Jeon]

머큐리얼은 아니고 git 이긴 합니다만, 

노트북 들고 출장가서 작업하느라 사내 서버 못들어갈 때도 로컬에 작업히스토리 쌓아둘 수 있고 나중에 머지할 수 있는건 좋더라구요 ㅎ 

Sent from my iPhone

[장준성]

저의 경우 이제 2개월 정도 써봤는데 다음과 같은 것이 좋았습니다.

1. 서버와의 연결이 필요없습니다. 회사 네트워크와 떨어진 곳에서 잘 동작합니다.

2. 브랜치가 많이 나뉜 경우 머징이 훨씬 편합니다.

    작업 자체를 중복 구현 없이 머징만으로 잘 관리한다면

    두 브랜치에 중복 적용된 내용이라도 프로그램에서 머징을 잘 추적해주기 때문에

    머징이 단순하게 처리되는 경우가 많습니다.

    작업을 잘 관리하는 부분은, 서브 버전과 마찬 가지로 어렵긴 하지만, 관리만 잘 되면 편합니다.

3. 브랜칭, 머징의 접근 비용이 많이 줄어듭니다.

    브랜칭이 서브 버전에서는 큰 작업이었지만, 머큐리얼은 일상적인 작업이라서

    브랜칭과 머징이 굉장히 쉽게 발생하게 됩니다.

    그에 따라 개인적으로 훨씬 쉽게 브랜칭을 접근할 수 있게 되었습니다.

4. 잦는 로컬 커밋으로 단위 작업을 더 잘게, 쉽게 이해할 수 있습니다.

    서브 버전에 잦은 커밋은 부담이지만, 머큐리얼의 잦는 커밋은 전혀 부담이 없습니다.

    머지 후 푸시만 잘 관리해주면 로컬에서 굉장히 추적이 쉽도록 커밋을 관리할 수 있습니다.

    작업 자체에 큰 도움이 됩니다.

5. 로컬 저장소의 수정이 용이합니다.

    로컬 저장소에서는 아직 푸시되지 않은 리비전을 지우고, 다른 곳에 붙이고, 하는 등의 작업이 쉽습니다.

    가끔 후회하는 작업들의 처리가 로컬 저장소에 한해서는 쉽게 가능합니다.

머큐리얼의 경우 서브 버전과는 조금은 방식으로의 접근하지 않으면

제대로 쓰기 어려운 것이 같습니다.

서브 버전 중심의 관점이 아닌 중립적인 관점에서 바라보면 쉽지 않을까 생각되는군요.

2011년 10월 17일 오후 5:33, Dajinsol Jeon <midg...@gmail.com>님의 말:

[Sungchul Park]

매번 커밋과 푸시를 하는 패턴이시라면 굳이 SVN에서 Hg로 갈아타실 이유가 없어 보입니다.

소규모 팀이 늘 네트워크에 연결된 상태에서 작업하신다면 SVN같은 중앙 집중식 SCM에서 Hg같은 분산 SCM으로 갈아 타면서 얻는 유익이 거의 없고 지금 말씀하신 것 같은 불편함(?)이 더할 겁니다. 개인적으로 git 보다는 hg가 익히기 쉽다고 생각하지만 아무래도 SVN에 비하면 둘 다 복잡하기는 마찮가지죠.

다만

• 오프라인에서 일하는 때가 많고
• 대규모 소스 트리를 여러 모듈로 나눠 분산된 팀이 작업하는 경우

Hg 장점이 크다고 봅니다.

이왕 전사 표준이 정해졌다니, 푸시는 진짜 필요할 때만 하고 자주 (다른 사람 눈치 볼 것 없이 기분 내킬 때 마다 마음껏) 로컬에 커밋하는 방식으로 사용 패턴을 바꿔보시라고 권해드립니다.

이미 아실지 모르겠지만 조엘 스폴스키의 hg 학습 사이트를 소개합니다.

http://hginit.com/

그리고 hg 기반의 비트버킷을 인수한 아틀라시안 사 내부에서 SVN을 hg로 바꾼 이야기도 참고할 만 합니다.

http://blogs.atlassian.com/developer/2011/02/moving_to_mercurial_-_why_we_did_it.html
http://blogs.atlassian.com/developer/2011/03/goodbye_subversion_hello_mercurial.html

그런데 50메가짜리 동영상을 버전 관리하시나요? ^^;;;
머지 결과가 마음에 안 든다는 것도 의외군요. 연구해볼 만한 부분 같습니다.

[김정훈]

수원님의 ps에 빵터졌습니다.ㅎㅎ(사실 그런 마음이 있어서 이제까지 버티고 있었긴 합니다..)

홈페이지에 번역해주신 조엘의 글도 예전에 읽어보았지요. 그리고 저도 hg merge를 치고는 느긋하게 커피를 마실줄 알았습니다-_-;

근데 현실은 좀 달랐습니다. 일단 성철님이 말씀하신 

• 오프라인에서 일하는 때가 많고
• 대규모 소스 트리를 여러 모듈로 나눠 분산된 팀이 작업하는 경우

이 경우가 저희팀에서는 전혀 해당되지 않습니다. 작업은 오로지 회사에서만 이루어집니다.

또 모듈단위로 나누어져 있지 않고 서로가 같은 클래스를 수정할 확률이 상당히 높습니다.

commit후 바로 push를 하는 이유가 commit을 모아뒀다가 push를 했다가는 다른 사람이 작업한 부분과 충돌이 발생되서

merge지옥이 펼쳐집니다. merge결과가 마음에 안드는 것이 아니라 같은 클래스를 수정한 경우 제가 보기엔 충분히 자동 merge가 가능한 상황인데

conflict를 내버립니다. 이렇게 되면 변수나 클래스이름 rename한번 하는 것도 대단한 일이 되어 버립니다.

심지어는 어떤 상황도 발생했냐면 pull을 하는 것을 깜박하고 commit을 합니다. commit하고 push하려고 하면 pull받으라고 오류가 납니다.

pull을 받으니 충돌이 납니다. 힘들게 충돌을 해결합니다. 그러고나면 merge된 것이 commit이 됩니다. 그래서 다시 push하려고 하면

그 사이에 누가 또 먼저 push를 했습니다. 그럼 또 merge해야 합니다. 이건 완전 지옥이죠. 그래서 commit하고나면 잽싸게 push를 해야 합니다. (그사이에 누가 push하면 머지해야하니까)

솔직히 제발 제가 뭔가 이해를 못하고 잘 못 사용하고 있는 것이었으면 좋겠습니다.

아 그리고 50메가짜리 동영상은 저희가 소스말고도 기획서도 같이 넣어서 관리하는데 제작한 자료 중 일부입니다. 

프로젝트에 관련된 자료는 모두 한곳에 관리하는 것이 편해서 말이죠. 이전에 SVN을 사용할 때 다른 프로젝트에서는 그래픽팀에서도 SVN을 이용하여

그래픽 소스를 관리했습니다. 그 떄는 이것보다 훨씬 용량이 커도 문제 없었구요.

2011년 10월 17일 오후 7:11, Sungchul Park <gyu...@gmail.com>님의 말:

[Sungchul Park]

> 이 경우가 저희팀에서는 전혀 해당되지 않습니다. 작업은 오로지 회사에서
> 만 이루어집니다.
> 또 모듈단위로 나누어져 있지 않고 서로가 같은 클래스를 수정할 확률이 상
> 당히 높습니다.
> commit후 바로 push를 하는 이유가 commit을 모아뒀다가 push를 했다가는
> 다른 사람이 작업한 부분과 충돌이 발생되서 merge지옥이 펼쳐집니다.
> merge결과가 마음에 안드는 것이 아니라 같은 클래스를 수정한 경우 제가
> 보기엔 충분히 자동 merge가 가능한 상황인데 conflict를 내버립니다. 이렇
> 게 되면 변수나 클래스이름 rename한번 하는 것도 대단한 일이 되어 버립니다.

그렇다면 설계에 문제가 있는 건 아닐까요?
한 클래스가 너무 많은 기능을 한다거나 정체성을 갖지 못하고 범용으로 사용
된다거나 하는 상황 말입니다.
각 클래스가 기능별로 책임이 명확히 부여돼 있다면 며칠 커밋 안 하거나 한
두 주 브랜치 땄다 다시 머지하더라도 지옥을 경험하는 일 따위는 거의 일어
나지 않습니다. 매번 커밋할 때 마다 머지 충돌이 걱정된다면 이건 SCM의 문
제가 아니라 설계 문제로 보여지네요.

> 2011년 10월 17일 오후 7:11, Sungchul Park <gyu...@gmail.com

> <mailto:gyu...@gmail.com>>님의 말:

>
> 매번 커밋과 푸시를 하는 패턴이시라면 굳이 SVN에서 Hg로 갈아타실 이
> 유가 없어 보입니다.
>
> 소규모 팀이 늘 네트워크에 연결된 상태에서 작업하신다면 SVN같은 중
> 앙 집중식 SCM에서 Hg같은 분산 SCM으로 갈아 타면서 얻는 유익이 거의
> 없고 지금 말씀하신 것 같은 불편함(?)이 더할 겁니다. 개인적으로 git
> 보다는 hg가 익히기 쉽다고 생각하지만 아무래도 SVN에 비하면 둘 다
> 복잡하기는 마찮가지죠.
>
> 다만
>

> * 오프라인에서 일하는 때가 많고
> * 대규모 소스 트리를 여러 모듈로 나눠 분산된 팀이 작업하는 경우

[iprever]

저도 아래 회장님의 의견을 쓰려고 했는데 이미 질문을 하셨네요^^

저역시 이 질문을 하려고 했는데...

질문:설계관점에서 먼저 문제점을 고려할 필요가 있지 않을까요??

Sent from my iPhone

[Youngrok Pak]

2011년 10월 17일 오후 8:20, Sungchul Park <gyu...@gmail.com>님의 말:

이 경우가 저희팀에서는 전혀 해당되지 않습니다. 작업은 오로지 회사에서 만 이루어집니다.
또 모듈단위로 나누어져 있지 않고 서로가 같은 클래스를 수정할 확률이 상 당히 높습니다.
commit후 바로 push를 하는 이유가 commit을 모아뒀다가 push를 했다가는 다른 사람이 작업한 부분과 충돌이 발생되서 merge지옥이 펼쳐집니다. merge결과가 마음에 안드는 것이 아니라 같은 클래스를 수정한 경우 제가 보기엔 충분히 자동 merge가 가능한 상황인데 conflict를 내버립니다. 이렇 게 되면 변수나 클래스이름 rename한번 하는 것도 대단한 일이 되어 버립니다.

그렇다면 설계에 문제가 있는 건 아닐까요?
한 클래스가 너무 많은 기능을 한다거나 정체성을 갖지 못하고 범용으로 사용 된다거나 하는 상황 말입니다.
각 클래스가 기능별로 책임이 명확히 부여돼 있다면 며칠 커밋 안 하거나 한 두 주 브랜치 땄다 다시 머지하더라도 지옥을 경험하는 일 따위는 거의 일어 나지 않습니다. 매번 커밋할 때 마다 머지 충돌이 걱정된다면 이건 SCM의 문 제가 아니라 설계 문제로 보여지네요.

설계 문제라기보다는 Collective Code Ownership과 관련이 있는 것 같습니다. CCO를 하는 팀에서는 다른 사람이 작성한 클래스를 고치는 일이 아주 빈번합니다. 특히 TDD까지 결합되면 더 심해지구요. 게다가 플랫폼에 따라서 무조건 발생하는 conflict도 있습니다. 아는 사람은 알겠지만 project.pbxproj는 악명 높죠. 

회사에서만 작업하고, 히스토리보다 팀원간 코드가 빨리 싱크되는 게 중요한 프로젝트이고, 긴밀하게 협업하는 프로젝트라면 분산 SCM은 득보다 실이 더 많습니다. 로컬 커밋의 장점을 이야기하는 사람도 많지만, 요즘 IDE에서 자동으로 local history를 관리해주는 경우가 많아서 로컬 커밋의 필요성도 점점 줄고 있고, 또 중요한 건 커밋이 아니라 내 코드가 팀 내에 빨리 공유되는 것이기 때문에 push 없는 commit의 의미는 크지 않습니다.

브랜치의 경우에는 release 브랜치와 dev 브랜치를 상시적으로 따로 운영해야 할 필요성이 있는 경우라면 git나 hg가 좀 유리한 면이 있긴 하죠.

분산 SCM이 유리한 경우는 오픈소스처럼 장기간에 걸쳐서 async적인 느슨한 협업이 되는 경우, 혹은 local histroy 기능이 없는 IDE를 사용하는 경우 등입니다. 

그러나...

또 git나 hg가 유행이기 때문에 과거 CVS를 Subversion이 대체했듯 git가 대세가 되어가고 있기 때문에, 앞으로 많은 툴들이 git나 hg 기반으로 나올 것이고, 오픈소스들도 github를 중심으로 나오고 있는 추세라, git에 적응해두지 않으면 난감한 일들이 많이 생길 수 있을 겁니다. 그러므로, git나 hg로 전환하는 자체는 어쩔 수 없는 일일 수도 있고, 그러므로 우리는 애자일 팀 답게(?) git나 hg의 단점들을 극복할 수 있는 방법을 찾아야겠지요.

한 가지 좋은 방법은 페어프로그래밍입니다. 그럼 push하는 사람 숫자를 반으로 줄일 수 있기 때문에 merge 복잡도가 반으로 줄어듭니다. 노..농담 아니구요;;

그리고, Daily Standup Meeting도 conflict를 줄이는데 큰 도움이 됩니다. conflict가 날 만한 작업인데 merge가 끔찍할 것 같은 작업들을 아침에 미리 예상할 수 있게 되면 서로 알아서 페어를 하거나, 혹은 작업 순서를 조정하거나 하게 되죠.

또, 개인적인 경험으로는 git가 hg보다 좋은 것 같습니다. 일단 성능이 좀더 좋은 것 같고, pull과 update가 한 번에 되서 hg에서 자주 겪는 문제, commit하고 push하려는데 conflict 나서 다시 pull, update, commit 해야 하는 문제가 훨씬 적습니다. hg가 git보다 더 쉽다고 하는데, 저는 그냥 비슷했던 것 같고, gitx가 꽤 직관적이어서 좋았던 듯.

diff-merge 도구를 좋은 거 쓰는 것도 중요한 것 같습니다. 가능한 한 적은 부분을 conflict로 표시하고 알아서 잘 합쳐주는 게 좋은 툴이죠. 얼마 전에 누가 diff merge 툴 비교글을 올렸는데 링크는 찾기 귀찮고, Source Gear에서 나온 게 공짜 중에 젤 괜찮다는 말만 기억에 남습니다.

아, 그리고 cron에 git pull을 걸어둔 적도 있었는데 좀 도움이 되었던 듯. 

[iprever]

흠 아무리 CCO를 한다고 저렇게 서로가 코드수정이 빈번하다면 개발된 코드에 대한 커밋전 아키텍트 코드리뷰가 필요하지 않을까 하는 생각 듭니다.

만약 CCO가 맞다면 애자일에 핵심 요소중 하나인 패어와 코드리뷰 그리고 리펙토링후에 커밋을 하는게 좋을 것 같아요.

Sent from my iPhone

[김정훈]

답변 주신 많은 분들께 감사합니다!

설계에 대해 지적해주신 부분은 생각못했던 부분인데 관련된 영향을 검토해보겠습니다. 특히 자주 충돌이 나는 부분을 통계를 내본다던가 하면 개선점을 찾을 수도 있겠네요.

다만 설계문제를 감안하더라도 동일 프로젝트를 SVN과 Hg(Mercurial) 동시에 써봤을 때 차이가 있었습니다.

현재 저희팀은 저를 포함하여 4명이고 기본적으로 2인 혹은 3인이 페어로 작업을 하고 있습니다.(상황에 따라 유기적으로 바뀝니다)

처음에는 서버와 클라이언트를 분할해서 작업했으나 지금은 4인이 모두 구분없이 작업하고 있고

Daily Standup Meeting, 주간회고, 플래닝포커, 2주의 이터레이션, CI, CCO, Hudson과 Trac 연동 등 다양한 애자일 프렉티스를 실천하고 있습니다.(물론 하는 것과 잘! 하는 것과는 다르겠지요?ㅎㅎ)

TDD는 프로젝트 초기에는 잘 됐는데 하다보니 또 실패했구요-_-; 설계는 Framework 에 영향을 주는 작업의 경우 UML을 통해서

사전 검토후에 작업을 합니다. 동시작업자가 많지 않다보니 이전 프로젝트에 비해서 충돌은 확실히 적은편입니다만 그래도 불편한건 사실이구요.

영록님의 말씀을 듣고보니 SVN으로 돌아가는 것보다 결국 단점을 극복하는 방법을 찾는 것이 합리적으로 생각됩니다.

merge도구는 좀 더 연구를 해봐야겠습니다. 사실 3-way 머지에 대한 이해를 잘 못해서 이 부분을 좀 더 공부해야 할 것 같기도 하네요.

참고로 hg도 클라이언트들이 대부분 pull과 동시에 update가 되는 기능은 기본적으로 포함되어 있습니다.

저희 회사에서는 hg가 git에 비해 윈도우 환경에서 사용하기가 더 편하다고 해서 채택된 것으로 알고 있습니다.

이렇게 이야기를 늘어놓으니 저는 아무 문제가 없고 Mercurial이 문제라고 이야기하는거 같아서 한심스럽기도하고

조엘의 말처럼 결국 자기 합리화를 하다가 SVN으로 돌아가는 전철을 밟는 것 같기도 해서 참 답답합니다.

창피하지만 부족한 부분이 있으면 확인하고 개선하도록 하겠습니다. 기존에 해왔던 것들도 제대로 하고 있는지 다시 한번 확인해봐야겠네요.

2011년 10월 17일 오후 9:09, iprever <preve...@gmail.com>님의 말:

[CHAE.SW]

저는 참 편한 삶을 살았군요.

저도 예전에 특정 부분에서 변경이 많이 일어나는 파일을 통계툴(svnstats)을 이용해서 찾아내서 아키텍트와 함께 문제를 해결해본적이 있었습니다.

비록 그당시 상황은 여러명이 한 파일을 건드리는 상황은 아니었고,

특정파일이 지속적으로 변경되는 상황이었습니다만, 어쨌든 전략패턴 + 권한체인 패턴을 써서 풀었습니다.

관련해서는 잘 해결되시길 기원하겠습니다.

아.. 그리고

애자일을 전방위적으로 적극 사용하고 계시네요,

괜찮으시다면 언제 한번 불러주세요. 

큰 방해 안된다면 회사로 찾아뵙겠습니다. 

분위기와 상황이 궁금하네요. : )

2011/10/17 김정훈 <won...@gmail.com>

[Sangcheol Hwang]

저는 조금 다른 의견인데요.

굳히 뭐가 유용한지 모르고 일반적인 경우를 따졌을때도 유용하지 않다면 기를쓰고 써야 하는 이유는 무엇인가요
처음 도입하려고 했던 이유를 한번 곰 씹어보시죠.

나중에 트렌드가 될거니까 지금 학습비용을 지불한다. 나중에 필요할때 지불하면 되지 않을까요.
Git이 편해서 Git을 쓰는게 아니라 GitHub가 편해서 Git을 쓴다는 분도 있더라구요.
나중에 더 편하게 쓸수 있는 도구가 얼마든지 나오지 않을까요?

저는 도구나 기법을 사람들이 불편해한다면 분명 무슨 이유가 있을거라고 생각합니다.
그 부분도 한번 같이 고민해 보시죠. 설계에 문제가 있을수도 있다는 의견  참 좋다고 여겨지네요.

넓게 한번 보시죠.

2011/10/17 CHAE.SW <doo...@gmail.com>

--
Blog: http://pragmaticstory.com
Twiter: @k16wire

[박성철]

기본적으론 저도 같은 생각입니다. 

git, mercurial 모두 리눅스 개발에 쓸 것을 염두에 두고 개발된 것인데 굳이 SVN으로 충분한 규모에서 뚜렷한 목적없이 복잡한 시스템을 쓰는 건 문제를 키운다고 봅니다.

SVN이 느리고 자주 깨지는 문제가 있더라도 나름의 해결 방법이 없는 것도 아니고, 로컬 저장소를 가지고 싶은 개발자가 중앙 SVN을 두고서 개인적으로 git이나 hg를 운영하는 것도 가능하니 말이죠.

하지만 지금은 전사적으로 표준이 그리 정해졌다니 그 틀에서 잘 쓰는 방법을 생각해보자는 것 같습니다. 

좌우간 채수원님 말씀처럼 저도 함 구경가고 싶네요. ^^

2011. 10. 17. 오후 11:54 Sangcheol Hwang <k16...@gmail.com> 작성:

[Outsider]

글을 보다가 든 의문인데

hg에서 저정도로 conflict가 자주 발생한다면

단계만 다를 뿐 svn쓸때도 동일한 현상이 있었을것 같은데요.

hg에서만 유독 conflict가 발생하는건가요?

2011/10/18 박성철 <gyu...@gmail.com>

--
/************************************************

Outsider

Front-end & Server-side Developer

Blog : http://blog.outsider.ne.kr

Twitter : @Outsideris

G-Talk : outsideris@gmail.com

*************************************************/

[Youngrok Pak]

자주 발생한다기보다, 발생할 때의 스트레스가 더 크다는 문제일 겁니다.

발생할 떄의 스트레스가 더 큰 이유는 몇 가지가 있는데, 하나는 hg에서는 commit만 하다가 모아서 push를 하게 되는 경향이 있는데, 그러면 한 번 push할 때 다른 팀원의 변경 내용과 conflict 나는 부분의 크기가 커집니다.  svn에서 자주 커밋 안할 때 생기는 문제와 같죠. 설령 계속 pull/update를 해가면서 작업하더라도 push하고 나면 다른 팀원들은 급격한 변화를 맞게 됩니다.

또 하나는, conflict가 났을 때 처리하는 과정의 단계가 더 많아서 상대적으로 unstable한 상태로 오래 있어야 한다는 거죠. 수동 머지는 제가 쓰는 용어로 "돈 세는 일"에 해당하는 일이라, 중간에 인터럽트를 받으면 안되고 빨리 끝내야 하는데, 평소에는 별 거 아니던 pull / update / commit / push의 스텝이 이 때는 부담으로 작용합니다.

그리고, commit하고 push하려다가 conflict 때문에 못하고 다시 pull을 한 후 update, merge 후 다시 commit하게 되는 상황은 아주 흔하게 발생합니다. pull -u를 하는 습관을 들이면 되겠지 생각하기 쉽지만, hg를 좋아하고 오랫동안 써온 사람들도 흔하게 이런 실수를 하는 걸로 봐서 좀 실수하게끔 설계된 인터페이스가 아닌가 싶기도 하구요.

비교하자면 svn에서 commit하다가 실패해서 update하고 merge, 다시 commit하는 거랑 같은 과정인데, 스텝이 많다보니 스트레스가 좀더 증폭되는 것 같습니다.

이런 점을 제외한 순수한 conflict의 발생 확률은 SCM에서 사용하는 merge 알고리즘에 달린 것 같습니다. git는 비교적 자동으로 잘 merge해주는 느낌이더군요.

2011년 10월 18일 오전 1:09, Outsider <outsi...@gmail.com>님의 말:

[SangHee Kim]

안녕하세요. 김상희라고 합니다.

저는 회사에서 2년 전부터 git 을 전파하고 있고 대규모 프로젝트(100명 이상의 개발자)를 git 을 통해서 두 번째
진행하고 있습니다. 그 전에는 4년 정도 clearcase 를 사용했었습니다. mercurial과 git이 다르기는 하지만
DVCS 관점에서 정훈님께서 말씀주신 사항을 중심으로 몇 가지 제 생각을 말씀드릴까 합니다.

=== commit 만들고 remote 로 push 도 해야하는게 번거롭다. ===
alias 와 같은 것으로 두 단계를 한 단계로 합쳐서 할 수 있을것 같습니다. 실제 git 에서는 그렇게 사용하시는 분들이
종종 계시고, svn 명령어로 대체해서 사용하시는 분들도 계십니다.

하지만 이렇게 이전보다 한 단계가 더 있다는 것을 완전히 반영하기 전에 '한번 더 보는 기회'로 삼아서 작업할수도 있고, 제
경우 실제 주의깊게 보는데 사용하기도 합니다. 또한 이 단계에서 해볼 수 있는 기능들도 존재하기 때문에 이 부분은 툴의
특성이라 생각하면서 그 특성이 가지는 긍정적인 면도 작업하시면서 찾아보시면 어떨까 합니다.

=== commit 하기 전에 pull 안하면 conflict 이 자주 발생한다. ===
내가 A라는 시점에 소스를 받아서 작업하고 B라는 시점에 올리기 전에 remote 의 최신버전을 받아와야 덜 문제가 생기는
것은 맞습니다. 하지만 다른 SVC도 업데이트에 대한 부담감이 없는 것은 아니라고 생각합니다. 익숙함의 차이때문에 더 부각되는
면이 있지 않을까요?

더불어 conflict 이 특히 자주 발생하는 곳이 있을것으로 생각합니다. 이 부분들을 찾아보시고 (예. merge 커밋의
conflict 파일들을 통계낸다) 동일 부분에 자주 conflict 을 내는 분들과 함께 이야기를 해보시면 좋을것 같습니다.
그리고 한 분이 그곳을 담당해서 작업하던가, remote 에 올리기 전에 이 분들끼리 merge를 한다던가 (일종의
moderator)하는 형식으로 대개 회피가 가능합니다.

실제 작년에 100명 넘게 같이 한 프로젝트에서 이러한 방법으로 괜찮은 효과를 봤습니다. 이러한 부분은 이렇게도 생각해볼 수
있습니다. '자주 업데이트 되는 부분에 대해서 더 많이 이야기를 하고, 더 많이 신경을 써라.' 이렇게 생각하니 구조적으로
변경을 시도하고, 협업에 있어서 더 많은 이야기를 했던 모습을 본 적이 있습니다.

=== 제가 생각하는 DVCS 몇 가지 장점 ===
브랜치 작업시에 드는 비용(만드는데 걸리는 시간, 차지하는 공간 등)이 비교적 적다보니 토픽 브랜치를 과거보다 훨씬 더 많이
사용하게 된다는 것입니다. 그러다보니 좀 더 다양한 의도적인 작업도 하게됩니다. 과거 clearcase 를 썼을때는 브랜치
만드는 시간이 꽤 걸려서 브랜치를 적게 만들어서 작업을 했었습니다. 매 작업시 연습장이 몇 장 더 생겼다는 비유로 표현을
해보면 좋을것 같습니다. 마음에 안정감이 생깁니다. 브랜치 생성과 소멸이 간단합니다.

또 하나를 꼽자면 소규모 협업시에 따로 서버를 만들지 않고도 서로 remote 가 되어서 작업이 가능하다는 이점이 있습니다.
이를테면 제가 A라는 분과 작업할 때 가끔은 그 분의 로컬 저장소를 공유폴더로 만들어서 그 곳으로 바로 push/pull을
해서 작업을 했습니다. 미국 출장시에는 타 회사 개발자가 USB에 자신의 저장소를 그대로 복사해서 제게 건네줬는데 제 로컬에서
바로 fetch 해서 사용할 수 있었습니다. 두 사례 모두 상당히 간단하고 빠릅니다.

만약 이렇게 하다가 문제가 생기면 그냥 로컬에 받아놓은 저장소를 지워버리고 다시 받으면 됩니다. 설정도 비교적 간단하고 받는
속도도 나쁘지 않은 수준입니다.

=== 기타 ===
몇 가지 아래와 같은 것들도 생각이 나서 적어봅니다.

- configuration 에 독특한게 많이 있습니다. 예를 들자면 git config 를 어떻게 설정하느냐에 따라서
개개인이 느끼는 편차가 꽤 컸습니다. merge 툴에 대한 세팅, binary 파일의 처리, merge 시에 어떤 것을
우선시하는가 등 이러한 config 가 mercurial 에 어떻게 존재하는지는 모르겠지만, 이러한 설정값에 대해서 알아보시면
도움이 될 것 같습니다.

- DVCS를 server - client 형태로 사용하시는것 같습니다. git에서는 이때 생각보다 server 의 스펙이
중요했습니다. 연산이 상당히 많아서 cpu나 memory점유율이 상당히 높아지는 것을 볼 수 있었습니다. 터무니 없이 느린
경험이 있으셨다면 server 격이 되는 remote 의 resource 를 확인해 보시는 것도 좋겠습니다.

Git 홈페이지에 가면 아래와 같은 소개가 있습니다.

'Git is a free & open source, distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.'

저는 경험적으로 이 말이 맞다는 것을 체험했습니다. 소규모부터 대규모까지, 그리고 peep-to-peer 부터
server-client 까지 모두 가능하다고 생각합니다. 다만 우려스러운점은 SVN보다 학습곡선이 상당히 좋지 않다는
것입니다. 이 부분은 시간과 적당한 교육으로 보완 가능하다고 생각합니다. (물론 이 작업은 상당히 어렵습니다.)

사용하시는 mercurial이 제가 접한 git과 다른점이 있어서 이 글이 도움이 되실런지 모르겠지만, 조금이나마 도움이
되기를 바랍니다. 재미있는 DVCS 삶 되시기를 바라겠습니다.

2011/10/17 김정훈 <won...@gmail.com>:

--
SangHee Kim
http://goo.gl/LnpDX

[Giwon Jang]

분산 버전 관리 시스템에 대해 이해가 쏙쏙 되네요. 좋은 글 고맙습니다.

[Lyle]

올해 초 XP2011 에 갔다가 거기 개발자들 중 많은 수가 git 아닌 hg 를 사용하고 있는 걸 보고 저도 올해 프로젝트를
진행하면서 hg 를 쓰고 있습니다. git 와 다른 부분이 별로 없다보니 어떤 장점이 있는지도 아직은 잘 모르겠더군요. 그냥
hg server 하면 웹에서 바로 볼 수 있게 해주는 정도?

반면에 불편했던 점은 꽤 명확한데, SVN 으로 미러링하는 부분이었어요. 몇가지 도구들이 있지만 굳이 git 에 비교하지 않아
도 절대적으로 활용성이 떨어집니다.

[CHAE.SW]

로그남깁니다. :)

지난 월요일에 정훈님을 Sungchul Park님과 함께 만나 뵈었습니다.

agile 관련해서 이런저런 이야기를 나누었습니다.

(성철 파크님은 무슨 일이신지 대화를 무려 녹음!!까지 하시더군요.)

그리고 사무실에서 머큐리얼 문제에 대해서도 살펴보았습니다.

이클립스 머큐리얼 플러그인을 쓰고 계셨고,

정말 간단한 파일도 자동으로 머지 하지 못하고 컨플릭트를 내면서 매뉴얼 머지를 종용하는 상황이더군요.

으응? 뭐지? 하면서 각자 흩어져서 재현해 봤습니다.

성철님이나 저나, 머큐리얼(hg)을 커맨드라인으로 실행했을때는 문제가 없었습니다만

이클립스를 이용하면 충돌이 발생하면서 동일한 문제가 발생하더군요.

정훈님의 '어떻게들 되고 계시삼?' 압박 메일 얼마 뒤 성철님이 바로 해결책을 찾아내셨습니다. :)

====성철님 회신 메일 =======

제가 보기에 이클립스용 머큐리얼 플러그인에서 update나 merge를 수행할 때 hg의 옵션으로 '--config ui.merge=internal:fail'을 주기 때문인 것 같습니다.

이 옵션은 이클립스의 머큐리얼 설정에서 Use external merge tool for resolving conflicts 옵션을 선택하면 제거 가능합니다. 제가 테스트해보니 정상적으로 머지가 되네요. 

한번 확인해 보시겠어요?

============================

저도 마찬가지로 옵션을 제외했더니 커맨드 라인때랑 같아지더군요.

재현 상황을 볼때도 '이거이거~ 플러그인 문제아냐?' 했었는데 역시나였습니다.

==== 제가 확인하고 보낸 메일 ===

성철님이 이야기 하신게 맞는것 같습니다.

저도 커맨드 툴에서는 이상이 없는데 마찬가지로 재현해 보니

계속 동일한 문제가 발생하더라구요.

강제로 매뉴얼 머지 처리를 하고 resolved로 마킹을 해야 하는 상황말이죠.

성철님 이야기 하신대로 해서 테스트 해보니

이제 커맨드 라인에서 할때랑 동일해졌습니다.

'뭐냐? 이건?? 하면서 좀 더 찾아봤더니

플러그인쪽 문제라고 봐야하는 게 맞는 것 같습니다.

http://stackoverflow.com/questions/4646789/merging-with-mercurialeclipse-has-conflicts-that-are-resolved-automatically-when

mercurialEclipse 플러구인 개발자는 머큐리얼을 믿지 말고 직접 해라! 라는 의미에서 그런 옵션을 걸어놓은것 같습니다.

======================

머큐리얼이클립스 플러그인의 기본 옵션으로 걸려있는 --config ui.merge=internal:fail 에 대해서는

http://mercurial.selenic.com/wiki/TipsAndTricks#line-227 에 의미가 잘 나와있습니다.

자동 머지를 하면 곤란한 파일 타입, 이를테면 exe, dll등을 위한 선택이었겠지만, 결과적으론 사용을 불편하게 만들어버렸네요.

이클립스 플러그인에서는 기본 옵션을 매뉴얼하게 조정하는 항목도 없으니까요.

(성철 파크님은, 그 옵션 메뉴가 그거인지 어떻게 찾아내셨을까? 와~)

요약

- 이클립스 hg 플러그인 기본 옵션이 문제!

- 성철님 말처럼 머큐리얼 설정에서 Use external merge tool for resolving conflicts 옵션을 선택하면 됨!

끝!

ps.

저를 포함해서 '설계를 살펴 보란말야!!'라고 말했던 사람들은 잠시 시간을 내서 창 밖의 파란 가을 하늘을 향해 묵념을...

2011/10/30 Lyle <mamadontgod...@gmail.com>

[Byeongweon Moon]

생각치 못했던 방향에서 해결책을 찾았지만. 둘러오는 과정에서 많은걸 배울 수 있었기에 다행이라고 생각합니다.

수고하셨습니다.

일일신 우일신

Byeongweon Moon

Blog : http://tasy.jaram.org.blog

2011. 10. 31. 오전 1:22 "CHAE.SW" <doo...@gmail.com> 작성:

[박성철]

무...묵념...;; (지하철 안이라서 하늘이 안 보이... ㅠㅠ)

PS 압박 때문에 알아보기 시작한 게 아니고 이클립스 플러그인 설치하느라 시간이 걸렸을 뿐입니다. 제가 컴맹이라...

2011. 10. 31. 오전 1:23 "CHAE.SW" <doo...@gmail.com> 작성:

[김정훈]

제가 월요일에 올리려고 했는데 수원님이 정리를 잘 해주셨네요.

역시 화장실 들어갈 때와 나올 때가 다르다더니 ' -';;

지난 주말에 팀원이랑 여러가지 테스트를 해봤는데 머지가 넘 잘 되여.ㅎㅎㅎㅎㅎ

너무너무 행복합니다. 이제껏 왜 이러고 있었는지 참 -_-;

그래도 덕분에 두분도 뵙고 잼있는 이야기도 나눌 수 있어서 참 좋았습니다.

게다가 성철님은 저희 회사 사장님과도 아는 분이었다는!

그리고 저도 성철님이 어떻게 그 옵션이 문제의 원인인지를 찾아내셨는지 궁금하네요.

2011년 10월 31일 오전 8:50, 박성철 <gyu...@gmail.com>님의 말: