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.
Received on 2011-07-20 14:13:50 CEST