> -----Original Message-----
> From: Paul Burba [mailto:pburba_at_collab.net]
> Sent: Wednesday, January 16, 2008 9:57 AM
> To: dev_at_subversion.tigris.org
> Subject: [RFC] Mergeinfo Inheritance and Elision in Mixed Rev
> Working Copies
>
> Right now our mergeinfo inheritance and elision code doesn't
> account for mixed rev working copies. In common practice
> this doesn't appear to be much of a problem. Here "common
> practice" is taken to mean merging into the root of a branch
> only where the branch doesn't have any subtrees with explicit
> mergeinfo.
>
> When merging to a branch root with subtrees with explicit
> mergeinfo or performing merges directly to subtrees of a
> branch, things still work in most common use cases, but we
> can produce incorrect elision/inheritance.
> Take a simple example:
>
> We have this WC:
>
> /trunk
> /trunk/a
> /trunk/a/b
> /trunk/a/c
>
> Copy '/trunk' to '/branch' at r2.
>
> Make a change to '/trunk/a/b' in r3.
>
> Make a change to '/trunk/a/c' and '/trunk/a/b' in r4.
>
> Merge r3 from '/trunk' to '/branch' and commit it as r5,
> creating svn:mergeinfo '/trunk:3' on '/branch'.
>
> Merge r4 from '/trunk' to '/branch' and commit it as r6,
> creating svn:mergeinfo '/trunk:3-4' on '/branch'.
>
> Now we update '/branch/a/c' to r5. This removes the change
> to '/branch/a/b' the first merge made, but '/branch/a/b'
> still inherits '/trunk/a/b:3-4' from '/branch' which is
> clearly wrong since only the change from r3. '/branch/a/b'
> should have explicit or inherited mergeinfo equivalent to
> '/trunk/a/b:3'.
>
> Here are a few options to fix this (I mention the first two
> only for completeness, I think they are both bad ideas!):
>
> 1) Do nothing. Provoking this situation requires a fairly
> contrived setup and the solutions to the problem have their
> own drawbacks (see below). But incorrect mergeinfo is still
> incorrect.
>
> 2) Change the behavior of update. If the update target
> doesn't have explicit mergeinfo, then set explicit mergeinfo
> from the repos. Of course this means that an update on a
> pristine WC could leave local mods and worse, it probably
> won't solve all the problems (it's such a poor idea I haven't
> gone much further with it to figure out where it might fall down).
>
> 3) When walking the WC to find a path's nearest parent with
> explicit mergeinfo to inherit (or to elide to) DON'T continue
> into parent paths unless they share the same working
> revision. This certainly solves the problem, but if the
> merge target tree is not uniformly updated to the same
> working revision it means we won't typically walk the WC
> looking for inherited mergeinfo. This has a couple of
> implications. First, it will increase the number of times we
> need to contact the server looking for mergeinfo since we
> can't rely on the inherited info in the WC.
> Second, it will result in more explicit mergeinfo as elision
> will be greatly curtailed (crippled really). Lastly, and
> this is no small thing, it makes elision/inheritance harder
> to explain to users than it already is.
>
> I'd like to implement 3 since all the problems associated
> with that solution neatly disappear *if* the merge target is
> at the same working revision. So we could just recommend
> updating the merge target before merging as standard practice
> (it doesn't need to be HEAD, it just needs to be consistent).
> And again, these problems don't manifest themselves unless
> the merge target has subtrees with explicit mergeinfo, so the
> problems don't come into play in the "typical" use case for merge.
>
> Any objections or alternate ideas?
In IRC glasser, markphip, and I kicked this around a bit and could see
no compelling reason not to do option 3. So it is done, in r28942.
Required only some minor changes to two merge tests and an update test.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-16 23:34:00 CET