[cvsnt] possible bug with Commit ID and -j options

Matt Schuckmann matt at schuckmannacres.com
Tue Jan 30 00:58:39 GMT 2007

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

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?

Matt S.

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook