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
