Re: Merging the subtree-mergeinfo branch back to trunk

Paul Burba <ptburba_at_gmail.com> writes:

> One thing to keep in mind if I didn't make this clear: The recording
> of mergeinfo on the *root* of the merge target is unchanged in this
> branch. If you merge ^/trunk -rM:N to branch_wc, branch_wc gets
> mergeinfo of '/trunk:(M+1):N' added to it, *always* (unless of course
> the merge is not mergeinfo aware, e.g. --ignore-ancestry). This
> branch only effects how subtree mergeinfo is recorded.

Yes, I did follow that.

>> But, I think the rationalization
>> is that it can't ever matter if changes that aren't actually changes are
>> recorded. I'm trying to articulate the rules to see if I can convince
>> myself this is ok, and having trouble. (I know I'm being redundant in
>> my comments below, but I'm just barely following myself.)
>>
>> Normally (if people follow the most straightforward CM rules), mergeinfo
>> is only at a module root. Each lower level object has implicit
>> mergeinfo which is the same.
>
> A point on terminology, you are talking about *inherited* mergeinfo
> here. Implicit mergeinfo is a path's history represented as
> mergeinfo. For example, say 'trunk' was created in r10. In r20 we
> copied trunk_at_19 to branch. The implicit mergeinfo for branch at that
> point would be '/trunk:10-19', a.k.a. it's 'natural history'. If
> that's not clear see
> http://www.collab.net/community/subversion/articles/merge-info.html.

I understood the concepts but got the terms wrong - thanks for
clarifying, as this is hard even if we all use the same words.

>> This means that --reintegrate, for example has to be able to say:
>>
>> every revision on the source path has been merged into every node
>> that is a child of the destination path
>
> Yes, which is what it has done since r34091 'Reintegrate the
> reintegrate-improvements branch back to trunk'.

I was trying to be careful about

r10: /branches/a copied to /branches/b

r11: /branches/a/bar gets subtree mergeinfo of /branches/c:9 (somehow)

r12: commits on /branches/a/foo

r13: /branches/a merged to /branches/b

so now
 /branches/b has mergeinfo of branches/a:11-12
 /branches/b/bar has mergeinfo of branches/c:9 [and no branches/a]

In this condition, every child of branches/b does not have effective
mergeinfo that indicates that all revisions that affect branches/a have
been merged.

It does meet the weaker condition that every child of branches/b (and
branches/b) has effective mergeinfo that indicates all non-null
revisions of the corresponding child of branches/a have been merged.

I am unclear what the current reintegration code checks.

> It depends what you mean by "do that again". A current trunk/1.6
> client would "do it again" by driving the merge editor for those
> missing revisions, even though the drives would be inoperative. If
> you had sufficiently large numbers of subtrees with explicit mergeinfo
> it might have to make these inoperative drives hundreds or even
> thousands of times. It will eventually do the right thing, it will
> just take a very long time to do it. The subtree-mergeinfo branch
> "does it again" by making a single call to svn_ra_get_log2() after
> which it can quickly figure out what parts of the requested merge are
> inoperative on the subtrees' remaining ranges. In many cases this log
> call won't be needed and won't happen (e.g. a release branch where the
> root and every subtree typically need the same set of revisions).

ok, that makes sense.

>> Reintegration: The subtree is not up to date because it is missing some
>> revisions. Now if you go check those revisions and verify that they
>> don't affect the subtree, you can say that it is up to date by a new
>> rule. Perhaps this new rule is easy, because one already has to allow
>> revisions that exist but aren't on the source path not to be in the
>> target mergeinfo.
>
> I've just spent some time looking at the reintegrate code and am now
> confident that no new changes are needed, reintegrate already does the
> right thing. As mentioned above, the reintegrate-improvements branch
> merged back to trunk in r34091 takes care of the case where the
> reintegrate source has subtrees with explicit mergeinfo. And since
> the dawn of reintegrate (i.e. r28979), the feature has handled
> inoperative gaps in the reintegrate's source that make it *seem* like
> the source is not fully synced with the target, see
> libsvn_client/merge.c:ensure_all_missing_ranges_are_phantoms().
> Combined, these are sufficient to make reintegrate handle the changes
> the subtree-mergeinfo branch introduces.

OK, then this all seems fine.

In my project we have about 20 people working in a tree with a long-term
branch for isolation of two subgroups, lots of ticket branches, and a
few stable branches. Once we have avoided the following:

  stray subtree merginfo from early 1.5

  people merging at other than module roots

  people commit changes to files during merges but not the mergeinfo

  proper record-only reverse merge of the reintegration changeset when
  reintegrating a branch and not deleting it

we have mostly been ok. Our remaining problem, not necessarily related
to your change, but perhaps is given by the following example.

The basic workflow is to create a branch where we manually choose
changesets to merge from parent to branch and back, often for a demo,
release, etc. Then when it's over, we merge all unmerged changesets
From parent to branch, and reintegrate. This is sort of a delayed
feature branch.

  create 'stable' branch (by stable, we mean that we don't routinely do
  a merge (of all unmerged changesets) from the branch's parent to the
  branch).

  cherrypick some revisions from parent to branch (via svn merge -c N
  parentpath). This works fine, and when we later get all unmerged
  revisions there is no issue.

  cherrypick some revisions from the branch to the parent (because the
  parent people want that fix right away)

Then, we we merge from parent to branch, we get self-conflicts.

I think what is needed is to do a record-only forward merge of the
reverse cherrypick merge. It would be really cool if this were
automatic, or somehow recorded so that this happened automatically.

But, I don't think my problem is changed by avoiding recording
inoperative subtree mergeinfo changes.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2380661