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.
On Wed, 7 Jun 2006 10:44:44 +0200, Andreas Krey <a.krey at gmx.de> wrote: >Gerhard Fiedler wrote: >... >> Branch A: that's where all other branches eventually end up. May be HEAD or >> anything else. >> Tag A1: developer B starts branch B. >> Tag A2: developer C starts branch C. >> Tag A3: developer C merges his changes from branch C back to A. >> Tag B1: dev. B needs the code from dev. C and merges it in from branch A. >> (repeat the cycle A2,A3,B1 ad lib) >> Tag A4: dev. B merges his code back to A. >> >> A >> | >> A1----->B >> | | >> A2-->C | >> | | | >> A3<--+ | >> | | >> +------>B1 >> | | >> A4<-----+ >> | > >... >> 4- Create the branches B and C and do the merge B1 as described. The >> advantage compared to 3 is that the final merge of B may be much easier. > >This is because all the work is already done during the merges >from A to B. If there are multiple ones this means that the >individual conflict resolution happens earlier that in the >'we only merge to A' scenario, and memory is fresher. :-) > >> Tony Hoyle called that "ouch messy" in another message :) and it may be, >> sometimes. > >The 'ouch' only referred (as I understood it) to the need to manually >determine which three files should be the input to diff3 (which is at >the heart of every merge). And this is *exactly* the job of a version >control system. > >... >> Most of my experience with extensive merges is with cvs servers (not cvsnt >> -- no merge points), so I cannot really comment much on how they work in >> any of these scenarios. > >I have some second-hand experience with clearcase which has mergearrows. >Thus, as I heard that cvsnt has them too, I immediately voted to switch >from cvs to cvsnt. Then I learned the hard way that merge arrows aren't >everything, update -j also has to take them into account! Clearcase does >this (getting the right inputs for diff3) in a fabulous way that I don't >quite understand anymore. > >... >> What might work is to use the change set of branch B /minus/ the change set >> from A1 to A4 -- that is, having a merge command option to tell cvsnt that >> all changes on A between the start of B and the tip of A should already be >> incorporated in B and that it should only consider the /other/ changes on >> B. (That would be a command for supporting specifically a scenario like >> option 4.) I'm not sure how realistic it would be to expect such an >> algorithm to work. > >For this case it is almost trivial. Let's put some more modifications >in the branches: > > A > | > A1------>B0 # Set branch B on version A1 (B0 is the same as A1) > | | > A2 | > | B1 > A3 | > >A and B have been busy. Now we want to merge A into B, which >in the end yields a revision B2 (for example because A now has >something that B needs to complete his work). > > *------->B2 # Merge A up to A3 into B. > >Obviously we need all changes from A1->A2->A3 and A1->(B0)->B1, >so the diff3 for merging must use A1 as base and A3 and B1 >as the leafs. > >Now we continue work. > > | | > A4 B3 > >and want to merge B back into A as our work there is completed. > >Now, since the revisions A2 and A3 are already present in B, >we can not base the merge on revision A1. Instead we need to >look into the graph finding the closest common revision, which >is A3. We have change lines A3->B2-B3 and A3->A4, meaning that >we need to do diff3 with A3 as base and A4 and B3 als leaves. > >Notice that the selection of versions to subject to diff3 is >actually independent of whether we are merging A->B or B->A. > >Also notice that we could regard the first merge as changing >the branch structure so that B is now effectively rooted in >A3 instead of A1 for determining all further merge operations. >After a merge the 'merged-over' part of the graph becomes >irrelevant for that. > >And finally this is just the same operation as if B were just >a sandbox. The merge A->B from A3 would be an normal update, >and the merge B<-A would be a commit (except that we always >need to merge into the sandbox first, granted). > This is exactly like I expected it to work but I could not express it as clearly as Andreas did. Basically once the merge from A to B is done the B branch should be treated as being based on the new merge source point in A (A3) for further merges. This way it does not matter if the commit in B following the A->B merge has been edited to exclude large portions of the code iin A from the previous branch point because in the future only the commits on B and A from the new branch point would be taken into account. Where is this view erroneous? HTH /Bo (Bo Berglund, developer in Sweden)