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.
Glen Starrett wrote: > 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. Merging is _always_ performed against the local sandbox. You shouldn't need to do this double hop unless you are trying to do the merge on a sandbox that is being used for something else (like a web site). And in that case, you shouldn't be doing that in the first place; everyone needs their own sandbox, including the web server. Normally, you work on the branch and commit your final changes. Then you switch your sandbox back to the trunk: cvs -q update -d -A and then attempt the merge from the branch to trunk cvs -q update -d -j Release-1999_05_01-bugfixes This will merge the changes on the branch into your local working copy; it doesn't do anything to the repository. You are free to blow away these files at this point and you lose nothing. Once you have done your testing, you can then commit those changes on the trunk. As for why your method causes every file to be marked as modified, without your actual commands (so it can be reproduced) anything I say is speculative. Create a mini repos and show each of your steps (with the actual command lines involved). John