On 19.10.2011 11:44, Johan Corveleyn wrote:
> On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov<paramon_at_acdlabs.ru> wrote:
>> On 18.10.2011 20:05, Daniel Shahaf wrote:
>>>
>>> Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
>>>>
>>>> What confuses people most now is the scattered
>>>> svn:mergeinfo ("Oh, why that dir has modified status, my merge
>>>> shouldn't have changed it!").
>>>
>>> Isn't this particular issue fixed in 1.7?
>>
>> No, it's apparently not. What was fixed is svn:mergeinfo physical storage
>> format and location in working copy. On the contrary, the
>> inheritance/elision rules were not (cannot be?) changed. Basically,
>> everything said in
>> http://www.collab.net/community/subversion/articles/merge-info.html about
>> "pesky implementation details" remains valid.
>>
>> Consider the following example. Users typically merge to /release/1.0.1/.
>> Merge info is recorded to svn:mergeinfo of /release/1.0.1/. Now consider
>> someone merges once to /release/1.0.1/some/subdir/. Possible reasons:
>> 1) Her changes belong only to some/subdir/.
>> 2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
>> /release/1.0.1/.
>> 3) She doesn't have access to /release/1.0.1/ at all, only to
>> /release/1.0.1/some/subdir/.
>>
>> Ok, now another user merges to /release/1.0.1/. Suppose his changes only
>> belong to another/dir. But he would see that /release/1.0.1/some/subdir/ has
>> modified flag! This is very confusing and hard to explain (I have tried).
>
> This precisely the behavior that should have been improved in 1.7 [1].
> So I'm surprised that it is not. You are testing this (the part with
> "now another user merges ...") with a 1.7 client, yes?
>
> [1] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>
Ah, I now tested a bit more thoroughly and I see that it's fixed indeed.
Very good, and sorry for the noise.
What about my other fears, bloated svn:mergeinfo and svn:mergeinfo
conflicts?
Best wishes,
Andrey Paramonov
Received on 2011-10-19 10:22:50 CEST