1:35 p.m.
Hello
I don't understand the following.
In version 1.4 the file contains
just the line (3 indicates line number)
--8<------------------------schnipp------------------------->8---
3 This is the line of version 4.
--8<------------------------schnapp------------------------->8---
In version 1.5
I Added a line (line number 5)
--8<------------------------schnipp------------------------->8---
5 this is the line of version 5 and I will kill line 3.
--8<------------------------schnapp------------------------->8---
And indeed killed line 3.
So I wanted to merge version 1.4 with 1.5 and expected:
--8<------------------------schnipp------------------------->8---
3 This is the line of version 4.
5 this is the line of version 5 and I will kill line 3.
--8<------------------------schnapp------------------------->8---
But I obtained:
--8<------------------------schnipp------------------------->8---
3 This is the line of version 4.
--8<------------------------schnapp------------------------->8---
Which is simply version 1.4.
I am puzzled, anybody has an idea.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:14 p.m.
Uwe Brauer writes:
So I wanted to merge version 1.4 with 1.5 and expected:
Hm. I would have expected you to get something identical to version
1.5. More on that below.
A merge is not an operation on two version; it is operation on two
patches to the same version, or equivalently, an operation on *three*
versions.
Normally the two versions that are apparently being merged are on
different branches, and the third version is usually computed as the
common ancestor:
B--C We want to merge C and E. So we trace back from C through B,
/ and from E back through D, to A, the common ancestor. Then
A we take all hunks of the diff A->C that do not touch lines
\ touched by the diff A->E, and apply them to A. Similarly we
D--E take all hunks of the diff A->E that don't touch lines
touched by the diff A->C, and apply those to A. Finally, if
there are any hunks of diff A->C that touch lines touched by diff
A->E, those hunks are *conflicts*, and you must resolve those by
editing the file to get the desired result in the conflict hunks.
In your case, the graph is trivial: "1.4--1.5", and the (forward)
merge would have 1.4 as the common ancestor of 1.4 and 1.5. The patch
1.4->1.4 is empty, of course, so all the hunks of the patch 1.4->1.5
are effective, and you would get 1.5 as the output of the merge.
You apparently invoked vc-merge in such a way that vc interpreted as a
reverse merge (which can be useful), and you ended up with version 1.4
as the output.
For more information, it might be useful to look at "info diff3"
and/or "man merge". The ediff manual also might go into some detail.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:36 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> So I wanted to merge version 1.4 with 1.5 and expected:
Hm. I would have expected you to get something identical to version
1.5. More on that below.
A merge is not an operation on two version; it is operation on two
patches to the same version, or equivalently, an operation on *three*
versions.
Right, I agree. Otherwise it would be patch and diff.
Normally the two versions that are apparently being merged are on
different branches, and the third version is usually computed as the
common ancestor:
B--C We want to merge C and E. So we trace back from C through
B,
/ and from E back through D, to A, the common ancestor. Then
A we take all hunks of the diff A->C that do not touch lines
\ touched by the diff A->E, and apply them to A. Similarly we
D--E take all hunks of the diff A->E that don't touch lines
touched by the diff A->C, and apply those to A. Finally, if
there are any hunks of diff A->C that touch lines touched by diff
A-> E,
those hunks are *conflicts*, and you must resolve those by
editing the file to get the desired result in the conflict hunks.
Let me try to elaborate this with an example and let us forget version
control.
Suppose the original file is
File1:
2 This is a test line.
Author 1 adds
File2:
1 This is an important fact.
2. This is a test line.
While author 2 adds
File3:
2. This is a test line
3. My text is better.
So merging file 2 and 3 (and in this case accepting the changes) should
lead to
1 This is an important fact.
2. This is a test line
3. My text is better.
So far so good: emerge does this and ediff (wordwise) as well.
Back now to version control.
Of course I could just use vc-version-other-window twice and run emerge
on these files, but that looks cumbersome.
So I want to use vc-merge somehow:
If I understand you correctly file2 and
file3 cannot be represented by version 1.2 and 1.3
but rather my branches. But which branches???
1.2.1 and 1.2.2 I presume
or
1.2.1 and 1.3.1?
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:34 a.m.
Uwe Brauer writes:
Let me try to elaborate this with an example and let us forget
version
control.
Examples taken out of the context of vc are irrelevant to using vc.
Back now to version control.
Of course I could just use vc-version-other-window twice and run emerge
on these files, but that looks cumbersome.
Why? That is the correct thing to do in this case, since you want a
result that ignores VC.
So I want to use vc-merge somehow:
If I understand you correctly file2 and
file3 cannot be represented by version 1.2 and 1.3
but rather my branches.
No. They can't be represented by (different) branches because they're
on the same branch. They therefore have a common ancestor which is
one of them, and the result of the merge then is the other.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5570
days inactive
5571
days old
3 comments
3 participants
participants (3)
-
Stephen J. Turnbull -
Stephen J. Turnbull -
Uwe Brauer