사내에서 Mercurial 에 관해 小규모 세미나를 했습니다.

변경사항을 push해서 최종적으로 어디에 모을지 결정하면 그곳이 DVCS 이전에 존재했던 불완전한 개념의 VCS에서 말하던 소위 중앙 저장소가 됩니다.

DVCS를 쓰면 모래상자(sandbox)에서 다른 곳으로 옮기기에는 불편한 모래성을 쌓으면서 개인적인 상태보존에 대한 안전장치 없이 불안불안하게 모래상자에 종속적으로 작업을 하던 불편함에서 벗어날 수 있습니다. DVCS 이전의 불완전한 개념의 VCS에서는 sandbox에서 작업중인 상태를 기록해 놓기가 애매합니다. 저장소에 commit을 하는 것은 보통 컴파일이나 유닛 테스트까지 하고 commit을 하는 게 권장사항인 경우가 많은데 그것 말고도 중간중간에 상태를 개인적으로 기록해 놓고 싶은 경우가 생깁니다. 하지만 아직 컴파일이나 유닛 테스트까지 해보지는 않았기 때문에 중앙 저장소에 반영한다는 것은 다분히 민폐라서 어쩌지 못하는 문제가 있었죠, cvs나 svn같은 기존의 DVCS 이전의 불완전한 개념의 VCS에서는 말이죠. 특히나 여러 개발 머신에서 작업해야 할 경우 DVCS의 장점은 가장 크게 드러납니다. 예를 들면 데스크탑서 작업을 하다가 랩탑으로 출장 나가서 작업을 해야 할 경우 DVCS라면 간단히 개인적인 상태를 기록하고(commit) 데스크탑 저장소에서 랩탑으로 끌어와(pull) 랩탑 저장소를 데스크탑 저장소에 뒤떨어지지 않게 업데이트 시킨 다음 출장 중에도 랩탑에서 작업을 하면서 랩탑 저장소에서 또 개인적으로 상태를 기록해(commit) 나가다가 돌아와서는 데스크탑으로 변경사항을 밀어넣으면(push) 됩니다. 이 때 랩탑에서 충분한 유닛 테스트까지 다 해서 정책적인 공동 중앙 저장소에 반영할 만하다면 랩탑에서 곧바로 중앙 저장소에다가도 밀어넣으면(push)되고, 그게 아니라면 데스크탑에서 마저 작업해서 공유할 만한 코드가 되면 그때 데스크탑 저장소에서 정책적인 공용 중앙 저장소로 밀어넣으면(push) 되는 등 어디서나 같은 개념의 저장소에서 유연하게 개발을 지속할 수 있습니다. DVCS 이전에 어쩔 수 없이 썼던 불완전한 개념의 VCS를 사용하고 있는 상황이었다면 단지 랩탑과 데탑 사이의 개발머신 동기화를 위해서 commit을 하는 왕민폐를 끼칠 수는 없으니 따로 모래상자(sandbox)에서 모래를 어떻게 퍼담았다 다시 가져올까 하는 삽질을 생각해야 하는 골치아픈 상황이 되고 말죠. commit이라는 명령어가 commit과 push로 기능이 나눠지기는 하지만 저장소라는 개념에서 보면 모래상자(sandbox)와 저장소(repository)가 따로 없고 모든 곳이 똑같은 저장소(repository)가 되기 때문에 사용자 입장에서는 사실 개념이 훨씬 더 간단해지는 것입니다. 그런데도 많은 분들이 복잡해진다는 오해를 하고 계신 것 같아 안타깝습니다.

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin