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.
When I'm about to merge in a branch back to MAIN, I first merge MAIN onto the branch so that testing and conflict resolution happen on the branch, not on MAIN. Then when I merge the branch to MAIN it is seamless, shortening the time my sandbox is being updated on MAIN. However, when I do this, every file that was updated on MAIN since the branch point is bumped up a revision with *no change* by this back-and-forth merge process. To detail a sample problem file (I changed the numbers to be simpler, my rev numbers are much higher): --File "foo.vb", verision 1.1. --Branch GRS is created, foo.vb is on the 1.1.2 branch. --foo.vb is modified on MAIN, now 1.2 --Branch GRS merges in changes, gets update from foo.vb. Now called 1.1.2.1 on branch, with a mergepoint of 1.2. --Now I merge changes from GRS back to HEAD. foo.vb merges changes from 1.1.2.1 to 1.2, with a "merge from" 1.1.2.1 (the pending mergepoint, right?). --> The local file is modified. CVS diff reports nothing (because there is no difference), yet I can (and do) commit it, and it gets a new revision number on HEAD (1.3). Why? Shouldn't cvs realize there is no change and not even modify the file on the merge from GRS to HEAD? It makes it more difficult to review the _real_ changes that have happened on a branch as I am merging changes in. Regards, Glen Starrett