Julian and Stefan, thank you for this distinction between the
"special" merge case, where we can grab all of the changes between two
revisions, and the "general" merge case. That really clarifies the
discussion.
The point I am making is that Subversion needs to support more of the
"general" merge cases. They are supported in other SCM systems, and
developers use them and need them.
The non-special merge case is also common even in projects that use
Subversion. For example, consider the case where we have a release
branch and a development trunk. I see this in almost every serious
subversion project. We move some bug fixes to the release branch. So,
it only has selected changes from the development trunk. We we also
make bug fixes on the release branch, or on branches that developers
make to fix and test the release version. We should be able to merge
those into the development trunk.
Stefan, thank you for explaining reintegrate merge. It makes more sense
to me now. I also see how with the current 2-URL merge, "merge
<branch>" can be ambiguous. If merge were redefined to mean "grab all
changes", and that were calculated internally, then you would not
specify two URL's, and the command "merge <from branch>" would not be
ambiguous.
On 7/20/2011 8:13 AM, Julian Foad wrote:
> Hi Andy.
>
> Let me talk a bit about 're-integrate' merges, which are a special case
> of 'cyclic' merges.
>
> Stepping back, just to make sure we all understand the concept and use
> the same terminlogy, we can define the high-level concept of a
> "re-integrate" merge in terms of the work flow of a "feature branch". A
> feature branch is made from what we'll call "trunk" and we develop a
> feature on the branch, keeping the branch periodically synchronized to
> trunk by doing a "catch-up" merge to get all the latest changes from
> trunk. When the feature is ready, a "re-integrate" merge is what we do
> to merge it (the feature, or equivalently the branch that includes the
> feature) back into trunk.
>
> There are (broadly speaking) two ways we could perform a "re-integrate"
> merge. The "general" way is to do it by using a sufficiently clever
> general-purpose merge algorithm to merge all the changes that are unique
> to the branch, onto the trunk. The "special" way is to recognize that,
> if the branch is up to date with trunk, then the desired state of the
> trunk is exactly the current state of the branch, so all we need to do
> is make the trunk look like the branch, which is theoretically a trivial
> operation.
>
> Both ways achieve the basic desired result when re-integrating a feature
> branch to trunk, and their differences, while significant, are
> relatively minor in context of the whole field of merging. The
> Subversion project implemented the "special" way, and I would guess that
> was mainly because the merge tracking was not clever enough to make the
> "general" way work, while recognizing that it's often helpful to have a
> simple concept on which to base a well-defined work flow so the loss of
> generality was not a big problem in many cases.
>
> Note that a practical benefit of the work flow using the "special"
> re-integrate is it ensures the reintegration will not generate any merge
> conflicts - neither physical, nor semantic (since we assume the branch
> has been reviewed and tested).
>
>
> On Mon, 2011-07-18, Paul Burba wrote:
>> On Sun, Jul 17, 2011, Andy Singleton wrote:
> [...]
>>> Mark notes that reintegrate does not work if you have subtree merginfo.
>>> The subtrees potentially make the top-level mergeinfo inaccurate.
> The "special" kind of re-integrate that Subversion performs has a
> logical pre-condition: that the branch must be up to date with the
> "trunk". In concrete terms, the required check is that the total set of
> mergeinfo on the branch must indicate that all changes from the trunk
> are included in full.
>
> The implementation of this check has been overly simple and pessimistic
> in the past. It is possible for the same merge history to be recorded
> in different ways. In some cases where mergeinfo is recorded on a
> subtree, the very same merge history could equally well be recorded in a
> single svn:mergeinfo on the root of the branch. The original
> "re-integrate" merge did not tolerate mergeinfo properties on subtrees
> at all, but that limitation was soon relaxed and I believe it has since
> been improved to logical completion so that now mergeinfo is allowed on
> subtrees as long as the total merge history described is logically
> correct.
>
> So I'm not sure if we still have design deficiencies in coping with
> subtree mergeinfo or not.
>
> The question of whether and how to implement a general-purpose merge
> that can cope with arbitrary re-integrates and other cyclic merges is a
> more complex issue that I have only begun to read up on. None of the
> above is meant to suggest that such an approach should not be attempted.
>
> - Julian
>
>
> [1] Here, "state" means the directory structure and file content, but
> not the history.
>
>
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Received on 2011-07-20 15:42:32 CEST