On Thu, Dec 10, 2009 at 12:22 PM, Paul Burba <[email protected]> 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/
