info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merge issue with deleted files


From: Cristian
Subject: Re: Merge issue with deleted files
Date: Fri, 6 Nov 2009 11:28:42 -0800 (PST)
User-agent: G2/1.0

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]