[Top][All Lists]

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

FW: CVS update issue using -j to merge files between a branch and the tr

From: Hamid Ghassemi
Subject: FW: CVS update issue using -j to merge files between a branch and the trunk
Date: Mon, 24 May 2004 14:12:07 -0700

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 (address@hidden)
Sent: Thursday, May 06, 2004 12:21 PM
To: 'address@hidden'
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


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:

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):

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: 

On the branch:

On the trunk:

Now do a "cvs diff <branchrevision>".  It'll show line 3 as being
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:
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.


reply via email to

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