Mercurial에서 이식편 사용의 결과

Mercurial에서 이식편 사용의 결과

---

최근 Mercurial에서 릴리스 브랜치를 유지할 때 변경 사항을 건너 뛰는 것에 대해 몇 가지 질문이있었습니다. 예를 들면 :

• Mercurial : 더미 병합 후 분기 별 변경 사항이 계속 돌아옵니다.
• 한 브랜치의 Mercurial 백 아웃이 다른 브랜치에 영향을 미치는 이유는 무엇입니까?

2.0에서 도입 된 이후 graft로이 문제를 피하기 위해 사용하는 것이 궁금했습니다 . 다음과 같은 수정 트리가 주어집니다.

A---B---C---D---E---F---G---H---I---J

Evil 변경을 건너 뛰는 릴리스 브랜치를 만들어야한다고 가정합니다 E.

hg update -r D
hg graft "F::J"

우리에게 :

A---B---C---D---E---F---G---H---I---J
             \
              --F'--G'--H'--I'--J'

• Q1 : 여기서 무슨 일이 일어 났습니까? 에서 transplant패치를 생성 F::J한 다음에 적용 했을 것이라는 것을 이해할 수 D있지만 graft패치보다는 3 방향 병합을 사용한다고합니다. 그래서 ....... 어떻게 작동합니까? 왜 더 낫습니까?

이제 수정 E하고 릴리스 브랜치에 병합 한다고 가정하겠습니다 .

                  --E2-----------------
                 /                     \
A---B---C---D---E---F---G---H---I---J---M1
             \                            \
              --F'--G'--H'--I'--J'---------M2--

M1은 직선 병합입니다. 특별한 것은 없습니다. M2는 "동일한"(또는 적어도 동등한) 변경 사항이있는 분기를 병합합니다.

• Q2 :이 병합은 보통 3 방향 병합 사용 D, J'그리고 M1?
• Q3 : 수은은 합병을 돕기 위해 이식 수술에 대한 추가 정보를 저장 / 사용 했습니까?

그리고 마지막으로...

• Q4 : 이와 같은 흐름의 잠재적 인 문제는 무엇입니까?

---

로 업데이트 D하고 접목 할 때 F::JMercurial은 여러 병합을 실행합니다. 이 병합으로 시작됩니다.

M = three_way_merge(local=D, other=F, base=E)

우리가 작성하는 경우 +d상태 사이의 델타 C와 D, 우리는 시작 :

        +d     +e     +f
---- C ---- D ---- E ---- F ----

그래프를 시계 방향으로 90도 돌리면 위의 3 방향 병합은 다음과 같습니다.

    -e  
  .---- D
 /
E
 \
  '---- F
    +f

즉,로 시작하여 E의 반대를 적용한 척 -e하여 D. 나는의 역 패치라고 생각한다 +e. 시작해서 E우리는 또한 F일반 델타 상태 로 갔습니다 +f. 여기에 이상한 아무것도 - 우리가 모든 상태를 (이 D, E그리고 F이미 저장소에). 다음과 같이 볼 수 있도록, 우리가 병합 할 수 있음을 분명 D하고 F.

병합은 "다이아몬드 완성"의 문제입니다. 우리는 새로운 상태 찾을 수 있도록 M의 혼합이다 D그리고 F어디에서의 차이 D로는 M유사하다 +f와의 차이 F에 대한이 M와 유사한입니다 -e. 다음과 같이 보입니다.

    -e     +f'
  .---- D ----.
 /             \
E               M
 \             /
  '---- F ----'
    +f     -e'

The +f delta became +f' and the -e delta became -e'. This is just a normal three-way merge, but the effect is interesting: we've applied F onto D instead of E!

After the merge, the second parent of M to F is dropped:

    -e     +f'
  .---- D ----.
 /             \
E               M
 \
  '---- F
    +f

To reiterate: We have copied the "effect" of F onto D, that is, we have found a delta (+f') that applied to D give the same effect as when +f was applied to E. We can straighten the graph a bit to get:

       +f'
--- D ---- M
     \
      '---- E ---- F
        +e     +f

The result is that F is grafted onto D using the full three-way machinery.

• Q1: What just happened here? So....... how does that work? Why is it better?

  A1: Using merges is better than patches since the merge machinery takes things like renames into account.

• Q2: Is this merge just a normal 3-way merge using D, J' and M1?

  A2: Yes, grafting does not alter the topology of the graph.

• Q3: Has mercurial stored/used extra information about the graft operation to help it with the merge?

  A3: No.

• Q4: What are the potential problems with a flow like this?

  A4: From a merge perspective it should work okay. It will duplicate some history which might be confusing for people.

---

Q1: It helps when there are conflicts. You can use your usual merge tool then (for me it's inline conflict markers, which I edit with Emacs' smerge-mode).

Q2: It's a normal merge.

Q3: No.

Q4: I think it's ugly to have two almost identical branches.

참고URL : https://stackoverflow.com/questions/9598704/consequences-of-using-graft-in-mercurial