Re: Propagation of inherited mergeinfo during URL->URL/WC copies

On Tue, Jun 5, 2012 at 1:10 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On #svn-dev today:
>
> [[[
> <danielsh> didn't know it was valid for svn:mergeinfo properties to
> have an empty value
>
> <pburba> danielsh: Yes, it allows the possibility for a subtree to
> inherit none of its (nearest) parent's mergeinfo.
>
> <danielsh> pburba: ie, prevent inheritance from an ancestor
>
> <pburba> danielsh: yes
>
> <danielsh> combined with a node that has no explicit mergeinfo
> <danielsh> pburba: thanks.  (I assumed it was not an error, but thanks
> for confirming)
>
> <pburba> danielsh: It rarely seen in practice...well at least I've
> rarely seen it
>
> <danielsh> pburba: I just saw an instance of it an hour ago.
> <danielsh> r820355 in /repos/infra/infrastructure
> <danielsh> basically a copy (or replace?) with history in a setting
> with no mergeinfo properties at all
>
> <Bert> danielsh: I remember that some very old (1.5 / 1.6 dev) clients
> created that property on local copies in some situations
>
> <pburba> Bert: Yeah, I don't recall if there were some cases with
> URL->URL/WC copies where it still happened
>
> <danielsh> the commit was done using svn 1.7.3
> ]]]
>
> So what happened here?
>
> First a little background:
>
> Since 1.5.5WC->WC copies don't record mergeinfo on the destination
> unless there is explicit mergeinfo on the source.  This was discussed
> here http://svn.haxx.se/dev/archive-2008-11/0432.shtml and here
> http://svn.haxx.se/dev/archive-2008-11/0297.shtml
>
> However, URL->URL/WC copies still carry the inherited mergeinfo from
> the source and make it explicit on the target.
>
> So what happened in r820355?
>
> (Paranoia alert: Since this revision involves a private portion of the
> ASF repository, the actual path names and other log info in this
> description are fictitious.  Probably overkill...)
>
> [[[
>>svn log -v -r820355 ^/
> ------------------------------------------------------------------------
> r820355 | bob | 2011-12-06 10:42:38 -0400 (Tue, 06 Dec 2011) | 1 line
> Changed paths:
>   A /infra/main/boxes/freebsd/harm8/usr/local/etc/postfix (from
> /infra/main/boxes/freebsd/harm8/usr/local/etc/postfix:820354)
>
> copy postfix from harm8
> ]]]
>
> ^/infra/main/boxes/freebsd/harm8/usr/local/etc/postfix_at_820354 has no
> explicit mergeinfo of its own, but its parent
> ^/infra/main/boxes/freebsd/harm8/usr_at_820354 has explicit empty
> mergeinfo on it:
>
> [[[
>>svn pg svn:mergeinfo -vR ^/infra/main/boxes/freebsd/harm8_at_820354
> Properties on '^/infra/main/boxes/freebsd/harm8/usr':
>  svn:mergeinfo
>
> ]]]
>
> So presumably what occurred was a URL->[URL | WC] copy, which
> calculated the source's inherited mergeinfo and made it explicit on
> the target.
>
> Now while this is expected, in this situation it is hardly ideal.
> Certainly cases exist where we *want* the inherited mergeinfo of the
> source carried to the destination (e.g. imagine
> ^/infra/main/boxes/freebsd/harm8 had real merge history representing
> merges from some third branch), but since the inherited mergeinfo of
> the source in this case is empty, it carries no useful information and
> could be safely ignored.  Another case comes to mind where this
> behavior is unnecessary, when the soruce and destination inherit
> mergeinfo from the same parent.
>
> I will file an issue.

http://subversion.tigris.org/issues/show_bug.cgi?id=4190

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba