(As discussed on your local #svn channel)
The Subversion server assumes that different files in a directory are
not related; because of that, it can merge unrelated directory changes
(file additions, removals, modifications). That's why commits can
proceed even if the directory in the working copy is not up-to-date.
File and dir properties are a lot like directory entries -- both are a
list of (name, value) pairs. If we decide different propeties are
unrelated, and that props are not related to dir lists or file contents,
the server could merge prop changes in the same way it merges dir list
changes. This would a) reduce the number of potential conflicts; and b)
incidentally fix this dir-prop-commit bug.
Thoughts?
Greg Stein wrote:
>On Tue, Jan 29, 2002 at 02:58:09PM -0600, Ben Collins-Sussman wrote:
>
>>...
>>Whoa thar, I never said it was a bug. It's a very deliberate decision,
>>even documented in doc/user/manual/dirversioning.texi.
>>
>
>It's a bug :-)
>
>>Imagine you have revision 7 of directory FOO in your working copy.
>>Now you add some props to FOO and commit, thereby creating revision 9.
>>
>>Why revision 9? Because unbeknownst to you, somebody added a new file
>>(BAR) to the directory in revision 8.
>>
>
>That would be a conflict.
>
>If rev 8 was created for an entirely different reason, then my property
>change should go through.
>
>>Of course, after you did your property commit, your working revision
>>number on FOO was bumped to 9. (You created 9, after all.) Now
>>whenever you do an update, you will *never* get that file added in
>>revision 8. The server thinks you already have it!
>>
>
>Agreed, and that is why this kind of change would be a conflict.
>
>>This is why we insist on directories being up-to-date when committing
>>properties on them.
>>
>
>Up to date with respect to its own changes. But not necessarily up to date
>with respect to the revision number.
>
>If I have:
>
> /
> FOO/
> BAZ/
>
>And everything is at rev 7. I add a property to FOO and commit. Meanwhile,
>somebody added a file to BAZ and created revision 8. My change should go
>through and should be rev 9.
>
>>Any commit will cause the committed item's
>>working revision to be "bumped", but in this case the bump could bring
>>about bad results. We need to make certain guarantees that when a
>>working copy directory is at version X, it actually has the same list
>>of entries (ignoring add/delete schedulings) as DIR:X on the server.
>>
>
>Agreed, and that is why we should generate a conflict for that case :-)
>
>Cheers,
>-g
>
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:01 2006