현재 우리 회사는 버전 제어를 위해 cvs를 사용하고 있습니다. 우리는 하나의 클라이언트 (물어 보지 말 것)를 위해 특별히 사용 된 오래된 코드 브랜치를 가지고 있습니다.수은을 사용하여 cvs 분기 병합
이 지점과 머리 사이의 델타 때문에 나는 머큐리얼의 병합 기능이 내 일을 좀 더 쉽게 만들어야한다고 생각합니다. 추론은 다음과 같습니다.
이 단계에서 저는 수은이 cvs보다 더 나은 merge support을 제공 할 것으로 기대합니다.
그런 다음 트렁크 저장소에 대한 변경 사항을 CVS에 다시 커밋합니다.
이 접근 방식이 효과적입니까? 이 전략은 내가 생각하는 것처럼 덜 고통스럽게 합병 될 것입니까, 아니면 제가 놓친 것이 있습니까?
Mercurial이 CVS 또는 Subversion보다 더 잘 병합하는 이유는 두 헤드/브랜치의 가장 공통적 인 조상을 추적하므로 정확한 정보를 제공하고 있는지, 아니면 결국 병합이 악화되었습니다.
이 같은 것을 할 경우 :
hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0 # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge
는 다음 두 머리의 공통 조상이 차이의 포인트가 될 것이다합니다 (CVS 명령이 잘못된 경우 죄송, 그것은 자비 롭게 긴 시간이었다).
문제는 POINT_OF_DIVERGENCE가 CVS 저장소에있는 곳을 아는 것입니다. CVS는이 점을 추적하지 않기 때문에 자체 병합에서 사용하지 않습니다.
CVS 모범 사례는 분기 할 때마다 분기점을 표시하는 태그를 만들지 만, 그렇게하지 않으면 앞에서 까다로운 사냥이 있음을 항상 제안합니다.
가장 최근의 공통 조상을 수정하지 않으면 Mercurial 병합이 CVS보다 개선되지 않습니다.
예, 작동해야하지만, 약간의 문제가있을 수 있습니다 (CVS에서 Mercurial로 소스를 가져 오는 방법 : hg convert 사용 또는 특정 버전의 수동 가져 오기 수행 등).
문제가 생겼을 때 새로운 질문을 만드십시오.
아주 간단한 히스토리를 제외하면 내장 된 변환 확장은 CVS에서 잘 작동하지 않습니다. 개인적으로는 처음으로`HG convert` 확장으로 이동하여 차이가 발생한 위치가 해결할 수 있는지 거라고
cvs2hg라는 cvs2svn의 포크를 사용합니다. 지점을 얼마나 잘 처리하는지는 모르겠지만 시작하는 곳이 될 것입니다. 나는 그것을 사용하는 원인을 결코 얻지 못했습니다. (고맙게도) –
제 경험으로 볼 때 분지가 갈라지는 지점을 추측하는 것은 끔찍한 일 이었지만, 그것은 오래 전이었습니다. 브랜치 포인트 태그 (CVS 베스트 프랙티스)를 가지고 있다면 명시 적으로하는 것이 더 낫다. –