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