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.
On Sat, 13 Jan 2007 09:46:44 +0000, Gerhard Fiedler wrote: ... > > True. But when you don't actually bring in everything from 1.2 then > > there should not be a merge arrow for that action in the first place. > > That depends. Maybe the same functionality has been added differently on > the branch and on the trunk. (Say both code lines needed to buffer/queue > some event that previously was handled directly, for different reasons.) > Obviously when you merge the code, you throw away one of the two > implementations (or both, and create an equivalent third). Yup. Same occurs when one line has undergone a restructuring so that the merge just yields a big conflicht and lots of manual labour is needed. > Merging (as I see it) is not "putting every code that's in both code lines > into one", it's "making the code do everything that's done in both code > lines, in a way that makes sense in the light of the changes in both code > lines". Which may result in substantial code changes in one or both code > lines during the merge. Yes, but that is true in any case of merges -- they don't always work automatically, and it may be some work to actually make a correct merge of all the functions from both source paths. But if you do that, then a merge arrow is in order; if you don't (as in the case described previously where you only take over selected functionality), then placing a merge arrow is incorrect. But that (merge actually merges all features) is independent of whether the merge is on code level or on a functional level. > In any case, there seem to be scenarios where merging back-and-forth isn't > safe; the disagreement is which these are exactly. Yes; in effect partial takeover of code or functions from one branch to another (within one file) are an abuse of version control, because you are doing things that the file history can't describe with merge arrows. > There is a solution > (unidirectional merge, with a branch copy at the end) that provides all the > benefits without the dangers of running such back-and-forth merges. This is a jump to the wrong conclusion. In our scenario we hade a branch into which we merge from the head and placed merge arrows accordingly. To get the branch work into the head we now have two choices: Do a backmerge into the head, or do a merge from the head into the branch and then copy the branch contents into the head. Assume the situation: 1.1---------+ | | | 188.8.131.52 | | 1.2 184.108.40.206 | | +-----> 220.127.116.11 Get more features into branch | | 1.3 18.104.22.168 Branch and head evolve further Now we are going to do it your way. We merge into the branch again and then copy the branch into the head: (1.3 22.214.171.124 Branch and head evolve further) | | +-----> 126.96.36.199 Get more features into branch | | 1.4 <=======X Do copy outside cvsnt. | For the merge we merge the diff from 1.2 to 1.3 into 188.8.131.52, yielding 184.108.40.206 which we then copy as 1.4 onto the head. Now, if we are doing it my way (patched cvsnt), then we simply do a backmerge: (1.3 220.127.116.11 Branch and head evolve further) | | 1.4 <-------+ Merge back into head, using patch | | This backmerge goes to merge the diff from 1.2 to 18.104.22.168 into 1.3, again yielding 1.4. Now, merging two versions with respect to a specific base (aka common ancestor) is a symmetric operation. In both cases 1.4 is diff3(a=1.3, base=1.2, b=22.214.171.124). Thus, merge forward and copy back produces the *same* result in the head as the merge-back-with-patch whose common ancestor selection Tony declared bogus. This also means that Michael Wojcik's scenario about the merge from 1.2 into 126.96.36.199 (the first merge into the branch) being selective breaks the merge-forward-copy-back in exactly the same way as the merge-backward-with-patch. > I fail to see the actual problem :) The only difference is that, after the merge-forward-copy-back, the branch is in a state where it can't be used anymore. And the copy-back is an operation that cvsnt does not provide and has to be done manually. Some accidental complexity that could be avoided, that's the problem. After all, with more bookkeeping you can do merges without any merge arrows. Andreas -- np: 4'33