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

[Matt Schuckmann]

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?

Thanks
Matt S.