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 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---------+
| |
| 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.
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=1.1.2.4).
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 1.1.2.3 (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