Re: Merge issue with deleted files

Cristian <[email protected]>
Newsgroups gmane.comp.version-control.cvs.general
Organization http://groups.google.com
Message-ID <958d217e-9b57-4fc3-ab79-b937b747aa70@s31g2000yqs.googlegroups.com>
Thanks for your reply Mark.

> By using the update command with the two "j" arguments, you'll "merge
> the differences between any two revisions into your working file."
> (source:http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC62)
>
> The way I understand it, it's as if you were to look at the diff from
> revision <first "j" argument> to revision <second "j" argument>, and
> apply that to what's in your checkout. Kind of like how "cvs diff -e"
> will create a set of commands that can be applied to the first revision
> to produce the second.

Right, that is my understanding also. In regards to using one or two -
j's - I have always felt that I need to have an explicit branch root
tag when I create a branch and since I have that I have always used
two -j's when I merge even if that was the first merge and I could
have used only one -j and have the root of the branch figured out by
cvs.

ie. File with common ancestor at 1.4 with rev 1.4.2.3 on branch A and
rev 1.4.4.2 on branch B. If I use only one -j (name of branch) then
cvs would figure out for me that it needs rev 1.4 as the common
ancestor. If I use two -j's then I am passing 1.4 explicitly as the
root tag of branch A, essentially the same thing. That is my
understanding anyway.

For this reason, I am very surprised not only at the fact that the
changes on the target branch were basically wiped out, but also to
find a different behavior between using one -j and two -j's.

> In this case, the diff between those two revisions is "remove file". So
> CVS applies a "remove file" to that file in your checkout. Would a
> conflict be more desired in this case?
>

Instinctively I would have thought that would be a conflict. I mean,
if I removed a file on one branch and done no revisions on the target
branch, then sure, I expect the file to be removed by the merge, no
question. But when the file on the target branch had changes in it
since the start of the dev branch, I would have never thought that it
would result essentially in a removal with no message. Very surprised
by these findings.


Thanks,
Cristian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.