[cvsnt] possible bug with Commit ID and -j options
arthur.barrett at march-hare.com
Tue Jan 30 12:55:42 GMT 2007
Any chance you can send the gzip'd RCS file to support at march-hare.com?
From: cvsnt-bounces at cvsnt.org on behalf of Matt Schuckmann
Sent: Tue 1/30/2007 11:58 AM
To: cvsnt at cvsnt.org
Subject: [cvsnt] possible bug with Commit ID and -j options
A couple of months ago we moved from an older CVS (I think it was some
flavor of 1.11) on Linux to (CVSNT) 2.5.03 (Scorpio) Build 2382 on the
same Linux box (same repository directories I think). So we have a
repository full of files with revisions with no commit id's on them.
Since the upgrade 2 new branches have been created with some new
revisions made on each branch.
Today I had a coworker come and ask me how to back out a change he had
just made on one of the branches, thinking wow I'm glad we upgraded to
CVSNT I can do this with 1 command using just the commit id for his
change, so I promptly showed him the quick and easy way to do it like so:
cvs up -j "@648e45be8935e7d7" -j"@<648e45be8935e7d7"
However, when we checked the changed files before committing we noticed
several changes to the files that he didn't make or remove. I updated my
sandbox with clean copies of the files and did it again just to make
sure and sure enough it did the wrong thing again.
Upon further investigation I found that for some of his changes these
were the first changes to that branch. Further more some changes had
been made to the other branch and the mysterious changes that we saw
were coming from the other branch. Upon reviewing the text spewed by
CVSNT during the merge it had done just that it had incorrectly
identified the other branch as the ancestor of the commit id on the
current branch and basically brought the changes from the other branch
into my sandbox instead merging with the branch point of our branch.
I'm assuming that this has something to do with the fact that none of
the revisions on the main trunk for these files had changed since we
upgraded the server and so they had no commit id's assigned and CVSNT
is doing something really stupid like looking for a commit id (any
commit id) previous in time to the one specified in the first -j option
instead of looking for the actual ancestors of the changed files.
Can anybody else confirm this as a bug?
cvsnt mailing list
cvsnt at cvsnt.org
More information about the cvsnt