On Tue, Jun 5, 2012 at 1:10 PM, Paul Burba <ptbu...@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@820354 has no > explicit mergeinfo of its own, but its parent > ^/infra/main/boxes/freebsd/harm8/usr@820354 has explicit empty > mergeinfo on it: > > [[[ >>svn pg svn:mergeinfo -vR ^/infra/main/boxes/freebsd/harm8@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
