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 firstname.lastname@example.org.
> 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. You are correct that if the dev branch has been re-based right up to the HEAD that this final merge back to the trunk is effectively a direct copy. My problem is that this functionality *used* to be supported by CVSNT and we have been using it successfully for quite some time and wish to continue to use it. Having to manually copy files introduces a manual element which increases the window for possible errors. Also, our process is of course not as strict as I have described. It allows for the engineers professional judgement in deciding if the very latest HEAD needs to be merged into the dev branch. If the only changes to the trunk since the last rebase are not significant or in a completely unrelated area, if may be worth skipping that step and merging directly to the trunk. With the old version of CVSNT the final merge into the trunk was performed exactly the same in either of the two scenarios. This simplified the process a lot and was a significant deciding factor in the choice to use CVS. > 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)? I know I'm not as clued up on the internals of merging as the folks who wrote CVS, but as long as you can generate the delta between any two revisions (not necessarily two revisions that are in the same development branch) and can apply that delta to any other revision (allowing for the possibility of conflicts) it should all hang together. The difficult bit is deciding the Root revision for any merge. That is what mergepoints are for. Using the example in my original mail: 1. Start with Trunk, Branch1 and Branch2 all at revision 1.1 2. Modify on Branch1 to create revision 220.127.116.11 3. Merge Branch1 to Trunk Target = 1.1 Source = 18.104.22.168 Common Ancestor = 1.1 No mergepoints between Target and Common Ancestor No mergepoints between Source and Common Ancestor Root = Common Ancestor = 1.1 Delta is Root -> Source = 1.1 -> 22.214.171.124 Apply to Target = 1.1 Target = Root, so no conflicts will be generated. Create revision 1.2, with mergepoint = Source = 126.96.36.199 4. Modify on Branch2 to create revision 188.8.131.52 5. Merge Trunk to Branch2 Target = 184.108.40.206 Source = 1.2 Common Ancestor = 1.1 No mergepoints between Target and Common Ancestor Mergepoints exist between Source and Common Ancestor 1.2 has mergepoint 220.127.116.11 18.104.22.168 is not ancestor of Target, ignored Root = Common Ancestor = 1.1 Delta is Root -> Source = 1.1 -> 1.2 Apply to Target = 22.214.171.124 Target != Source, so conflicts may be generated and will need to be manually resolved. Create revision 126.96.36.199, with mergepoint = Source = 1.2 6. Merge Branch2 to Trunk Target = 1.2 Source = 188.8.131.52 Common Ancestor = 1.1 Mergepoints exist between Target and Common Ancestor 1.2 has mergepoint 184.108.40.206 220.127.116.11 is not ancestor of Source, ignored Mergepoints exist between Source and Common Ancestor 18.104.22.168 has mergepoint 1.2 1.2 is ancestor of Target, becomes new Common Ancestor Root = Common Ancestor = 1.2 Delta is Root -> Source = 1.2 -> 22.214.171.124 Apply to Target = 1.2 Target = Root, so no conflicts will be generated. Create revision 1.3, with mergepoint = Source = 126.96.36.199 I realise I have probably over-trivialised it, but that seems to work for me. This is how the old version of CVS seemed to work (based on the results of my using it, not looking at the code). Please can you show me the scenario which results in loss of data? Rgds, Andy -- Andy Harrison - Platform Software Engineer Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ, UK "No matter how bad things seem... ...nothing could be worse than being used as a towel rail." - A.A. Milne A member of the Anite Group of companies. Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email. Anite Group plc Registered in England No.1798114 Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187 Scanned for viruses by BlackSpider MailControl.