[cvsnt] Mergepoint issues on 2.5.0.3 b2382

Gerhard Fiedler lists at connectionbrazil.com
Sun Jan 14 15:27:28 GMT 2007


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.


Andreas Krey wrote:

> 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.

I agree with this. I'm only talking about what we both seem to consider a
"correct" merge (one that deserves a merge arrow, one that completely
integrates functionality from both code lines).


>> 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---------+
>     |          |
>     |       1.1.2.1
>     |          |
>    1.2      1.1.2.2
>     |          |
>     +-----> 1.1.2.3  Get more features into branch
>     |          |
>    1.3      1.1.2.4  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      1.1.2.4  Branch and head evolve further)
>     |          |
>     +-----> 1.1.2.5  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 1.1.2.4, yielding
> 1.1.2.5 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      1.1.2.4  Branch and head evolve further)
>     |          |
>    1.4 <-------+     Merge back into head, using patch
>     |          |
> 
> This backmerge goes to merge the diff from 1.2 to 1.1.2.4 into 1.3,
> again yielding 1.4.

How does this continue? (Below you said that one of the differences between
the merge-back-and-forth approach and the merge-forth-copy-back approach is
that the branch can or can't be used...)

>    1.1---------+
>     |          |
>     |       1.1.2.1
>     |          |
>    1.2      1.1.2.2
>     |          |
>     +-----> 1.1.2.3  Get more features into branch
>     |          |
>    1.3      1.1.2.4  Branch and head evolve further
>     |          |
>    1.4 <-------+     Merge back into head, using patch
>     |          |

For further development on the branch, you need to get the 1.3
functionality on the branch. Let's also consider that the back merge
created a number of conflicts that had to be resolved, like taking code
out, some reorganizing and everything we agreed upon earlier that may
happen in a merge.

So, after the merge that created 1.4 (and maybe after some additional work
on both trunk and branch), you run again a merge from trunk to branch. How
does this work? Looks messy to me.


> 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.

Maybe in the head; I'm not sure. But it definitely doesn't produce the same
result on the branch.


>> 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. 

Why is this? We started out considering a scenario where one has a branch
that one wants to keep up-to-date with the trunk while implementing a
feature on the branch. So this line, right before the copy-branch-to-trunk,
would be necessary anyway: 

>     +-----> 1.1.2.5  Get more features into branch

After this line, the branch has all features from trunk plus the new branch
feature. So I can copy it to the trunk, if I want the branch feature there.
There's nothing that prevents me from continuing development on the branch,
say to enhance the new feature.

> And the copy-back is an operation that cvsnt does not provide and has to
> be done manually. 

I don't think this is correct. If you mean by "done manually" that one has
to use a command line command, you are correct. You could use a cvs update
command on the trunk to merge in the complete branch, from (branch) start
to (branch) tip. (After the 1.1.2.5. merge, of course.) Something like

  cvs up -j tagBranchStart -j branch 

run on trunk does the copy-back-to-trunk. It needs a branch start tag,
which is a good thing to have anyway. It also can be repeated after having
been done once, if one tags the branch at this merge (also a good thing to
do anyway) and uses now this new tag as start reference.

Gerhard


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook