[Top][All Lists]
[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