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.
Anders Bülow wrote: > I have this scenario: A deployment branch is made at a time, when > file1.cs is version 1.6 on the main branch, which is a development > branch. Later the version of file1.cs on main branch is version 1.12. At > this time the change made from version 1.8 to 1.9 is needed on > deployment branch. > Some time later, all changes made on deployment branch is > merged to main branch. This is done by making checkout of main branch, > and afterwards wincvs update with merge option merge with one tag > <Deployment branch name>. This works fine except for files like > file1.cs. > After my last merge, I have more then 300 changes files, so it is not an > option to check each file. I'm not sure such a merging scenario can be automated easily. Maybe it's an option to keep a list of files with such partial merges and at least merge these manually and review them closely. BTW, most people advise to check each merged file. I look at it this way: If the changes are trivial, it's quick and even 300 files don't take forever. (Been there, done that :) If they are not trivial, no matter how long it takes, they need to be checked... If you need half an hour to understand what happened during the merge, you probably shouldn't expect an automatic merge to do it without error in every case. Don't forget that with the number of merges the probability of a merge error increases -- faster than linearly, due to the increased possibility of unwanted interactions between individual merges. Finding a bug some time down the road can easily take more time than the check would have taken. A three-way visual diff tool helps (left side dev branch, right side deploy branch, middle merge result). Gerhard