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.
