2010-03-29 6 views
231

저는 Mercurial을 프로젝트에 사용하고 있습니다. (다른 곳으로 밀어 넣거나/당기지 않는 유일한 repo입니다).Mercurial - 이전 버전으로 되돌리고 거기에서 계속하십시오.

지금까지 선형 역사가 있습니다. 그러나 내가 현재 작동하고있는 현재의 상황은 끔찍한 접근법이며 시작하기 전에 다시 돌아가서 다른 방식으로 구현하고 싶습니다.

저는 Mercurial에서 branch/revert/update -C 명령과 다소 혼동 스럽습니다. 기본적으로 나는 버전 38 (현재 45)로 돌아가고 싶고 나의 다음 커밋에는 부모로 38이 있고 거기에서 계속 수행하고 싶다. 수정 39-45가 영원히 사라지거나 자신의 막 다른 지점에서 끝나는 지 신경 쓰지 않습니다.

어떤 명령/명령 집합이 필요합니까?

+6

관심있는 사람은 관련 사이드 바에 올라가서 되돌리기 대 업데이트에 대한 좋은 설명이 있습니다. http://stackoverflow.com/questions/2506803/difference-between-revert-and-update-in-mercurial – Paolo

답변

141
hg update [-r REV] 

나중에 커밋하면 효과적으로 새 분기를 만듭니다. 그런 다음이 분기에서만 계속 작업하거나 기존 분기를 병합 할 수 있습니다.

+0

감사합니다. 다음 커밋은 REV 예에서 수행됩니다. – Paolo

+6

다음 커밋은 새로운 분기를 만듭니다. 확실하지 않은 경우 저장소 (작업 복사본 포함)를 백업하고 테스트 해보십시오. 결과가 마음에 들지 않습니다.> 처음부터 무료로 시작하십시오. – van

+0

이것은 현재 변경 사항을 이전 버전과 병합하므로 모호한 답변입니다. 아마 당신이하고 싶지 않은 수정입니다. 정답은 되돌릴 수 있어야합니다. –

376

여기에 명령에 컨닝 페이퍼는 다음과 같습니다

  • hg update은 작업 카피의 상위 버전을 변경하고이 새 상위 버전에 맞게 파일 내용을 변경합니다. 즉, 새 커밋은 업데이트되는 개정에서 계속됩니다.

  • hg revert은 파일 내용 만 변경하고 작업 사본 상위 버전 만 남겨 둡니다. 작업 복사본의 파일에 대해 커밋되지 않은 변경 사항을 유지하지 않으려는 경우 일반적으로 hg revert을 사용합니다.

  • hg branch은 새 명명 된 분기를 시작합니다. 명명 된 브랜치를 변경 세트에 할당 한 레이블로 생각하십시오. 따라서 hg branch red을 수행하면 다음 변경 집합이 "빨간색"분기에 속하는 것으로 표시됩니다. 이것은 특히 다른 사람들이 다른 브랜치에서 작업 할 때 변경 집합을 구성하는 좋은 방법 일 수 있으며 나중에 변경 집합의 원래 위치를보고 싶을 수 있습니다. 그러나 당신은 당신의 상황에서 그것을 사용하고 싶지 않습니다. 당신이 hg update --rev 38를 사용하는 경우

은 다음 39-45은 막 다른 골목으로 남아있을 것입니다 체인지 - 매달려 머리를 우리가 부르는. 푸시 할 저장소에 "다중 헤드"를 생성 할 것이므로 푸시 할 때 경고 메시지가 나타납니다. 누군가가 합병을해야한다고 제안하기 때문에 그러한 머리를 남겨 두는 것은 무례한 일이므로 경고가 거기에 있습니다. 그러나 당신이 정말로 걸기를 원하기 때문에 당신의 경우에 당신은 그냥 가서 hg push --force을 할 수 있습니다.

다른 버전으로 개정판 39-45를 아직 푸시하지 않은 경우 비공개로 유지할 수 있습니다. 매우 간단합니다 : hg clone --rev 38 foo foo-38을 사용하면 리비전 38까지만 포함하는 새로운 로컬 복제본을 얻을 수 있습니다. foo-38에서 계속 작업하고 새로 작성한 (좋음) 변경 세트를 푸시 할 수 있습니다. foo 복제본에는 여전히 오래된 (나쁜) 수정 버전이 있습니다. 원하는 복제본의 이름을 자유롭게 지정할 수 있습니다 (예 : foo ~ foo-badfoo-38 ~ foo).)

마지막으로, 당신은 또한 hg revert --all --rev 38를 사용하고 커밋합니다. 이것은 리비전 38와 동일하게 보이는 리비전 46을 만듭니다. 리비전 46에서 작업을 계속할 것입니다. 이것은 hg update과 동일한 명시적인 방법으로 히스토리에 포크를 작성하지 않지만 다른 한편으로는 불평하지 않을 것입니다. 여러 개의 머리를 가지고있다. 리비전 45를 기반으로 자신의 작업을 이미 만든 다른 사람들과 협력하고 있다면 hg revert을 사용할 것입니다. 그렇지 않으면 hg update이 더 명백합니다.

+1

굉장한 대답. 나는 hg revert --all --rev ##을 사용했고 그것은 나의 엉덩이를 저장했다 : D –

+6

그리고 hg clone --rev 38 foo foo-38 그냥 내 것을 구했다. 감사!!! –

+6

+1 hg 되돌리기 --all --rev X 와우. 아름다운. –

27

난 그냥 내가 커밋 밀어했던 직후, 이전 버전에 하나의 파일을 되돌릴 필요로하는 경우가 발생했습니다. 이러한 개정을 지정하는 약식 구문은 이렇게 여기에서

hg revert path/to/file -r-2 

-2 그건 그냥 현재 커밋되지 않은 변경을 되돌릴 것 -1을 사용하여 커밋하기 전에 마지막 버전으로 되돌릴 것이라고 할 명령이다, 다른 답변이 적용되지 않습니다.

+0

나는 이것을 매우 유용하다고 생각한다. 물론 -r 옵션을 사용하면 수정 번호 – Alex

6

hg update -r REV를 사용하면 당신이 다음 밀어 수 있도록 그 변화를 저지하는 방법에 대한 질문에 대해 답 명확하지 않았다.

업데이트 후에 커밋하려고하면 Mercurial은 변경 사항이 없다고 생각합니다. 의욕 그때 나는 그것을 커밋 수, 나는 새로운 변화를 한 것으로 인식 있도록

은 내가 먼저 (A README에 말) 모든 파일을 변경했습니다.

그러면 두 개의 헤드가 생성됩니다.

밀고 전에 다른 헤드를 제거하기 위해, 나는 그 상황을 해결하기 위해 No-Op Merges 단계를 따랐다.

나는 그 때 밀 수 있었다.

+0

을 제공 할 수 있습니다. 이전 분기에서'commit --close-branch'를 할 수 있습니다. 새로운 머리를 밀기 위해 '밀어 넣기'를 할 수도 있지만, 현재의 머리를 혼란스럽게 만들 수 있습니다. –

7

IMHO, hg strip -r 39 정장 나은이 경우.

Martin Gisler가 권장하는 "복제 repo 방법"과 마찬가지로 mq 확장을 사용하도록 설정해야합니다. 변경 세트가 어떻게 든 게시 되었으면 (아마도) 어떤 시점에서 repo로 돌아갑니다. 현지 repo 만 변경했기 때문입니다.

+0

이 것에 대해 알지 못했습니다. 레포를 삭제하고 다시 복제하는 것보다 쉽고 깨끗합니다. 감사. – iamnotmaynard

3

위의 답변은 가장 유용했으며 많이 배웠습니다. 하지만, 내 요구에 간결하게 대답은 : ${1}이 개정의 수 또는 분기의 이름입니다

hg revert --all --rev ${1} 

hg commit -m "Restoring branch ${1} as default" 

. 이 두 행은 실제로 bash 스크립트의 일부이지만 수동으로 수행하려는 경우에는 잘 작동합니다.

릴리스 분기에 핫 픽스를 추가해야하지만 기본에서 빌드해야 할 때 유용합니다 (CI 도구를 올바르게 설치하고 분기에서 빌드 한 다음 나중에 릴리스 분기를 제거 할 때까지) .

1

나는 Tortoise Hg (Mercurial 용 무료 GUI)를 설치하여 사용했다. 다시 볼 수있는 개정판을 마우스 오른쪽 버튼으로 클릭하면 눈앞에 모든 커밋 메시지가 표시되고 '모든 파일 되돌리기'가 가능합니다. 직관적이고 쉽게 파일 세트 버전간에 앞뒤로 롤오버 할 수 있습니다. 문제가 처음 나타 났을 때 설정하려는 경우 정말 유용합니다.

관련 문제