On 19.10.2011 11:44, Johan Corveleyn wrote:
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
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
