On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov <para...@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 -- Johan
