머큐리얼에서는 저장소 설정이 매우 유연하다. 병합이 상당히 간편하므로 이를 이용해, 개발 과정에 따라 특별한 목적의 저장소를 만들 수도 있다.

요리법이 점점 상당히 좋아지고 있다^[1].

체인지셋 번호를 좀 더 자세히 살펴보자.

첫 번째 번호인 13은 짧고 간편하지만 유일한 문제는 믿을 수 없다는 것이다!

팀 원이 각자 작업하고 병합했을 때 이 짧은 번호는 동기화되지 않는다.

그러므로 ”좋습니다. 체인지셋 13에 해당하는 리비전을 출시합시다.“ 라고 항상 말할 수는 없다. 왜냐하면 13이 무엇인지는 서로 다르게 생각할 수 있기 때문이다. 이 때문에 복잡한 16진 숫자를 사용한다.

16진 숫자는 모든 저장소에서 같고 결코 바뀌지 않는다.

그러므로 “보세요, 오늘이 출시하는 날입니다! 체인지셋 번호는 1b03ab783b17입니다!” 라고 말할 수 있다. 그런데 체인지셋에 이름을 붙인다면 더 좋지 않을까?

이 역시 할 수 있다. 이를 태그(tag)라고 한다.

이제 로그를 살펴보자.

태그를 추가하는 그 행위 역시 체인지셋이며 자동으로 커밋된다는 점에 주의하자. 이제부터는 1b03ab783b17 대신 Version-1.0을 사용해 배포한 버전을 참조할 수 있다.

31층에서 제품 출시 파티를 하던 CEO가 좀 비싸 보이는 발포 포도주(sparkling wine) 한 상자를 갖고 내려왔다. 스탠(Stan)은 조금 취했다. 아니 조금이 아니다. 아무도 그런 모습을 본 적이 없었다. 그는 셔츠를 벗고 볼품 없는 군살이 아니라 근육을 뽐내면서 마케팅 부서에서 일하는 여성 몇몇에게 큰 인상을 주려 애썼다. “저 전등으로 턱걸이를 해 보죠.” 그는 자랑하며 말했다. (사무실에는 긴 형광등이 있다.) 그러곤 뛰어 올라 장식물을 잡자, 당연히 모든 게 바닥으로 떨어졌다. 그 것은 가는 피아노 줄 몇 가닥으로 매단, 10 파운드 정도로 가벼운 물건이었다. 하지만 그의 몸무게는 열띤 논란이 있지만 290에서 300 파운드 사이였다. 그는 모든 전등과 많은 천정 타일을 떨어뜨리고 유리와 방음 재료를 박살냈으며 꼬리뼈를 바닥에 부딪혀, 위험한 작업 환경을 만든 회사를 어떻게 고소할 건지 신음하며 투덜거렸다.

우리들 중 나머지는 다시 사무실 칸막이 안으로 돌아와 Guac 2.0에 대해 작업을 계속했다.

커밋한다.

이 요리법이 완벽하지 않은 건 말할 필요도 없다. 시험은 고사하고 아무 것도 하지 않았다. 그래서 한 손님이 부른다.

“너무 짜요!” 투덜거리며 말하지만 2.0 버전을 수정한 것을 기다리려 하진 않는다.

다행히 태그가 있었다. hg up을 사용해 저장소에 있는 어느 버전으로든 갈 수 있다.

이제 난 이 멍청한 소금 문제를 수정할 수 있다.

그리고는

머큐리얼에서는 내가 새로운 헤드를 만들었다고 알려준다. 이제는 조금 전에 작업하던 2.0과 방금 커밋한 1.1로 헤드가 두 개이다.

이제 이 것에 1.1로 태그를 붙여 고객에서 보내고, 버전 2.0으로 돌아가 작업을 계속 할 수 있다.

한 가지 문제는 소금 문제를 수정한 내용이 여기에 없다는 건데 어떻게 해결할 수 있을까?

이런. 태그를 병합해야 하는데 이는 머큐리얼 버그이다. 문제는 머큐리얼에서 태그는 이름이 .hgtags인 파일이며, 이 파일 역시 버전 제어를 하므로 종종 .hgtags 파일의 다른 버전을 직접 병합해야 한다. 아무튼 간단히 각 파일에 있는 내용을 모두 유지하면 된다.

출시 코드에 생각지 못한 작은 수정 내용을 추가하려 할 때는, 이처럼 이전에 태그를 붙인 버전으로 돌아가면 간단하다. 사실 소프트웨어 프로젝트 대부분에서는 항상 이런 일이 생기며 머큐리얼에서는 더욱 안정적인 방법으로 다룬다.

앞으로 출시할 버전을 작업하면서 동시에 버그를 수정하는, 멋지고 안정적인 방법을 보여주기 위해 먼저 1.0 이후에 작업한 모든 것을 되돌리도록 저장소를 1.0을 출시한 상태로 만든다.

저장소 하나에서 모든 것을 다 하는 대신 stable과 dev 두 개를 만드는 게 핵심이다.

stable 저장소에는 고객에게 출시한 마지막 중요 버전을 담아 긴급하게 버그를 수정해야 할 때 사용한다. 이 예에서는 1.0에 대한 모든 수정 내용을 담는다.

dev 저장소에서는 다음 버전 개발을 진행한다.

1.0을 출시하자마자 나는 stable을 dev로 복제한다.

이제 똑같은 저장소 둘이 생겼다.

두 저장소 모두 체인지셋 14까지로 이력이 같으므로 머큐리얼에서는 디스크에 두 복사본을 만들지 않도록 실제로는 파일 시스템 기술인 하드 링크를 사용한다. 이 때문에 hg clone은 빠르고 비용이 적게 들므로 계속해서 복제하는 것을 망설이지 않아도 된다.

이제는 dev 저장소에서 guac에 대해 작업을 시작한다.

그런 다음 stable 저장소에서 소금 문제를 수정한다.

여기에 태그를 1.1로 붙이고 출시한다.

그런 다음 stable에서 dev로 수정 내용을 가져온다^[2].

지금까지 한 내용은 다음과 같다.

이 복잡해 보이는 그래프를 이해할 수 있으면 머큐리얼을 잘 이해하고 있는 거다. 요점은 stable 저장소에는 버그 수정 내용만 있고 dev 저장소에는 새 코드와 수정 내용을 병합한 내용만 있다는 것이다.

다음은 다중 저장소를 사용하는 몇 가지 예이다.

• 몇 사람이 함께 기능을 만드는 팀 저장소를 만든다. 만든 기능이 잘 동작하면 팀 저장소에 있는 변경 내용을 주 개발 저장소에 넣어 다른 개발자가 사용 할 수 있게 한다.
• 테스터가 사용할 QA 저장소를 만든다. 시험할 코드를 주 저장소에 넣는 대신 QA 저장소에 넣어 테스터가 확인을 마치면 그 내용을 주 개발 저장소에 넣는다. 이런 식으로 주 개발 저장소에는 확인을 마친 코드만 남긴다.
• 각 개발자는 자신의 저장소가 있으므로 팀의 다른 사람이 변경한 내용을 건드리지 않고 동료가 시험으로 만든 내용을 가져와 확인할 수 있다.

크고 복잡한 조직에서는 이런 기술을 조합해 서로 간에 변경 내용을 가져오는 저장소를 구성할 수 있다. 각 기능은 시험과 통합을 거쳐 더 상위 저장소로 이동해 결국에는 고객에게 전달할 수 있는 주 출시 저장소로 들어간다.

확인하기

다음은 이 튜토리얼을 읽은 후 알아야 하는 것이다.

1. 이전 버전에 태그를 붙이고 다시 되돌아 간다.
2. 팀에 ‘stable’과 ‘dev’ 저장소를 구성한다.

아무튼 이 튜토리얼의 마지막까지 왔다. 머큐리얼에 대한 모든 것을 자세히 다루지는 않았지만 이를 바탕으로 더 깊이 나아갈 수 있다. 모든 것을 상세히 다룬 책도 있다. 질문이 있으면 Kiln Knowledge Exchange(StackOverflow 같은 곳이지만 Kiln 제품을 다루며 머큐리얼에 대한 질문은 더욱 환영한다)에서 하길 바란다.