On Thu, Dec 10, 2009 at 12:25 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
I fixed svn_mergeinfo_parse(), svn_mergeinfo_to_string(),
svn_mergeinfo__catalog_to_formatted_string(), and
svn_mergeinfo__to_formatted_string(), so that any time we create
svn_mergeinfo_t from a string or vice-versa, we tolerate relative
paths in the input, but create absolute paths in the output. This
solves the original problem Mike saw with his sync merges...
>> Properties on '.':
>> svn:mergeinfo
>> /subversion/trunk:879653-880579
>> subversion/trunk:880580-880583
>
> FWIW, we already have this problem on our 1.6.x branch.
...but in cases like this branch, it actually makes things worse,
because when the second "identical" key/val is parsed, it overwrites
the first one, so we lose mergeinfo during merges and get partial
(i.e. wrong) answers to svn mergeinfo queries. We should be able to
simply merge the results for identical keys (I'll look at that
tomorrow). Other than that I don't see any other problems, beyond
what I already mentioned regarding svn_mergeinfo_diff (which isn't
much of a problem).
Paul
> 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.
Received on 2009-12-11 05:39:18 CET