This was sent by a co-worker of mine on May 6th. However for some reason it did not get to the mailing list. So I am sending this again.
Hamid Ghassemi -----Original Message----- From: Joe Reifel ([EMAIL PROTECTED]) Sent: Thursday, May 06, 2004 12:21 PM To: '[EMAIL PROTECTED]' Subject: CVS update issue using -j to merge files between a branch and the trunk I did a search for this, but was unable to find it so I'm reporting it as new. Thank you in advance for reading this long email. Here's the easiest way to reproduce this is. Start with a file 3 lines long: the quick brown Add it to the trunk. Then branch. cvs tag -b MERGE Now do a double check-in of a change into both branches. In the trunk, change the third line to be in all caps (BROWN), and check it in. Do the same with the branch. Now the branch and the trunk contain the same file contents: the quick BROWN Then in the branch, change the third line back to small case (brown). Now the branch contains the following (mimics the original file at the branch point): the quick brown Of course in the real world, many changes may have happened to the file on the branch along the way, this is just the simplest way to show it. So here's what we have so far: Point of merge: the quick brown On the branch: the quick brown On the trunk: the quick BROWN Now do a "cvs diff <branchrevision>". It'll show line 3 as being different. Now do a "cvs update -j MERGE <file>". The update process happens, and it will return without error. It'll also return without merging anything. The resulting file will be the following: the quick BROWN <----still in caps, the change from the branch didn't come down I know *why* this happens, but I don't agree with it. There was no diff between the branch and the branch point on the trunk, so no change was considered for the merge. At least that's how I understand it based on how it behaves. Cvs did actually do a good job of telling us that it was merging with the branch point; however, without a clear understanding of what impacts that might have created, along with performing a merge of 100's of files at once, this one tidbit got missed -- in fact, it took a lot of time looking at it to even make sense of what it was telling us. Other processes caught that this happened shortly after the merge so it was no big deal, but I can't help but wonder if this can be avoided in the future. It created a lot of paranoia about the merging process. I would have expected it to compare the branch with what there was in the trunk, then clearly it would have seen a diff. Then, if it would have noticed that line 3 was *also* changed on the trunk, it would have thrown a merge conflict, then the developer would have had a say in what version he/she really wanted. This is where I think the bug is. That all said, we are running CVS v1.10 here, perhaps this was fixed in a later revision, but I couldn't find mention of this on the website, so I don't know if it's fixed, I was hoping you could comment. Thanks! -Joe- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs