Re: Merging the subtree-mergeinfo branch back to trunk

Paul Burba <ptburba_at_gmail.com> writes:

> Back in March I created the subtree-mergeinfo branch to explore the
> ramifications of not setting mergeinfo on subtrees unaffected by a
> merge. Currently if you perform a merge tracking aware merge of URL
> -rM:N to WC_TARGET, then every path under WC_TARGET with explicit
> mergeinfo has that mergeinfo updated to reflect the merge of URL
> -rM:N, regardless of whether the subtree or any of its children were
> affected by the merge.
>
> If you are not already nodding your head regarding the implications of
> this, then this excerpt from
> http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/overview.txt
> sums it up:

I would normally hesitate to post somewhat, but the relative silence to
some of the questions I've posed on this list makes me feel like I am
part of a small minority who can understand what you are doing. It
seems like there might only be 50 people in the world who really
understand svn:mergeinfo....

Your proposed change makes me nervous, because it seems to break the
property that all merges are recorded. 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. Subtree mergeinfo is created for various
reasons, and those mostly aren't important to this discussion. When a
node has subtree mergeinfo (meaning a node has mergeinfo and we are
doing a merge operation at a higher level node), then the effective
mergeinfo for the node is the value of the subtree mergeifo, which
*replaces* the mergeinfo of the path being operated on.

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

Operationally, this means

  (1) in the mergeinfo for the destination path, the sourcepath:N-M
  appears where N is one more than the common ancestor, and M is the
  most recent revision that touched anything on sourcepath

plus it also means

  (2) pin every path which is a child of the destination path, the
  effective mergeinfo contains sourcepath/subpath:N-M

which translates to

    (3) paths with subtree mergeinfo have N-M
  and
    paths without subtree mergeinfo are descendents of paths that
    satisfy (1) or (3)

I can certainly see the argument, that I think this branch makes, that says

  merging no changes to a path is not anything that we need to record,
  because the notion of whether a null merge has or has not happened
  does not ever matter

This is a combination of 1) what happens when merging again and 2)
reintegration.

Merging again: By the subtree mergeinfo rules, those child nodes have
not merged the revisions that aren't listed. So do you have to do that
again, which means looking at those revisions, even if you conclude that
it will not change the subtree?

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.

So by now I've convinced myself that this is ok, as long as the
reintegrate check follows what I've outlined.

I am most curious whether you think I have understood this correctly or
am confused.

    Greg

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