On Thu, Dec 10, 2009 at 12:22 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> This fix does however, produce some odd side effects based on the fact
> that mergeinfo that differs only by the leading slash is considered
> the same. So the svn_mergeinfo_(diff|merge|remove) APIs behave oddly.
> For example, if we checkout the issue 3242 branch @888941 we see the
> relative path mergeinfo that the "bad" load into the ASF repos
> produced:
- snip
>
> # With the patch in place (this is a 1.6.x client) a merge
> # covering already merged revisions now works...
>
> issue-3242-dev-wc>svn merge ^^/subversion/trunk . -r0:880583
> --- Merging r880580 through r880583 into '.':
> U tools\buildbot\master\master.cfg
>
> issue-3242-dev-wc>svn st
> M .
> M tools\buildbot\master\master.cfg
>
> # ...and while diff appears to show that the mergeinfo
> # has changed only by the newly merged revisions...
>
> issue-3242-dev-wc>svn diff --depth empty
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/trunk:r880580-880583
>
>
> # ...when we actually look at the mergeinfo we see that
> # *all* of it has been quietly "fixed" to absolute paths:
FWIW, this all looks like what I would want it to do. "Fix" the
property but hide the details in diff.
> Properties on '.':
> svn:mergeinfo
> /subversion/trunk:879653-880579
> subversion/trunk:880580-880583
FWIW, we already have this problem on our 1.6.x branch.
I am entirely favor of tolerating the missing slash but "silently"
fixing it when we update the property. Showing that in diff would
just be noise that I do not think anyone would care about seeing.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2009-12-10 18:26:15 CET