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.
Harrison, Andy wrote: > Since this proved to be a very simple and easy process, we took it one > step further. Before the development branch was merged into the trunk, a > final re-base we performed. This way all the regression testing we > needed to do can be done on the development branch before the code went > anywhere near the trunk. If I understand you correctly, at this point you have in the development branch the trunk code plus the new feature -- exactly what you want to have on the trunk afterwards. > This then means that the final merge into the trunk is a trivial affair. Your problem seems to be that you merge this code back into the trunk, when there is no need for a merge. The code on the branch as it is after the last merge from the trunk is what you want to have on the trunk -- if you have done the merges from the trunk to the branch correctly. (If not, you need to find these problems either way.) So a move of the code on the branch to the trunk should do it; there's no need for a merge. AFAIK this code move is not directly supported by cvsnt, but the earlier thread Tony E mentioned showed some solutions for this close to its end. > Please can you explain to be exactly how this (or another scenario) > might result in lost data? If you look at merging in terms of deltas between revisions and try to write down the delta handling for a simple case of back-and-forth merging like you described (don't forget to include some manual conflict resolution), you see that this is non-trivial even for simple cases. That's basically the reason why it's better to merge in one direction, end up with the final code in the branch you are merging to, and then move this code to where it belongs. Can you describe in how this would be different from your current process (result-wise)? Gerhard