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? Thanks Matt S.