>> 2. When integrating, the changes on the child branch that result from
>> the rebase action (and thus are coming from the parent branch) do not need
>> to be integrated in the parent branch. Otherwise these changes will be
>> duplicated.
>
> If you have brought the branch up to date, i.e. you have rebased it up to
> the current head revision, then integrating is simply equivalent to copying
> the branch to the trunk. (The change that needs to be added to the
trunk is
> simply the current difference between trunk and branch.)
That is correct, and I also suggested that in the third point of my
original posting. You only need to be sure that nothing has happened on
the trunk between your 'rebase' and your 'copy', otherwise, these changes
are overwritten.
> If you haven't yet brought the branch up to date, then there are likely to
> be conflicts and you shouldn't be trying to integrate it.
Well, it depends. I also think it is good practice to do the integration
on the local branch and not directly on the parent branch or trunk, but
nothing prevents you from doing that.
> So I don't see why you would need transitive merges etc. in this
> situation.
In fact, a rebase/integrate cycle is kind of a transitive merge. Say that
we have parent branch P and child branch C. C branched from P at revision
3. After developing a while on branch C, we want to do a rebase. But in
the mean time, P has been changed by changesets 5 and 6. The rebase
action results in changesets 5 and 6 to be merged in C, commited in
revision 8. Now, if we want to integrate C in P, we need to merge the
changes on C from revision 3 to 7 (excluding 8) to get it right. When
merge tracking is implemented, I assume that I would just be able to merge
from 3 to HEAD, and that the merge tool would notice that revision 8 is
not really 8, but 5 and 6 from the parent branch, so it would not be
integrated anymore (or replace 5 and 6, see my note below). So a
rebase/integrate cycle is kind of transitive from P to C and then from C
to P. But indeed, true transitive merges (with at least 3 parties) are
not applicable in this situation. I only think that solving the
rebase/integrate cycle problem will also solve the transitive merge
problem.
* Now what was that nonsense about replacing changesets?
Well, in my original posting, I wrote the following:
> 3. What if the rebase action results in one or more conflicts? ... when
> integrating, this changeset is ignored because of the situation explained
> in 2. So there will be a conflict again ... When doing the merge manually,
> you would copy the conflicting files from the child branch to the parent
> branch...
What if instead of doing a copy on an integrate, you would be able to
replace the changesets that are merged by the changeset which recorded the
merge? Off course this would need to be generalized like this: "Merging a
changeset M that is itself the result of a merge from changesets C1 to Cn
that the target branch already contains, is done by replacing the original
C1 to Cn by M on the target branch". Would this be valid? Would this be
possible and solve our problem?
What would the merge tool do when trying to merge M (result of merging C1
and C2) to a branch containing only changeset C1? It cannot do the
replacement trick there. Whould it try to merge only C2? Or should it
result in a conflict? I assume the latter is the only correct solution,
since we would not be able to consider other possible changes that are
commited in M.
Gino
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 7 14:45:00 2005