Re: Commit bug?

Ben Collins-Sussman wrote:

>Greg Stein <gstein@lyra.org> writes:
>
>>As Ben said. There is a bug with directory properties. Update first (even if
>>you're the only person working on the repository). Then commit.
>>
>
>Whoa thar, I never said it was a bug. It's a very deliberate decision,
>even documented in doc/user/manual/dirversioning.texi.
>
>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.
>
>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!
>
Something's wrong here. How is changing directory properties
(conceptually!) different from adding a file to a directory? Does a
directory have to be up-to-date if you want to commit an added file?

I've a feeling this is a bit bogus. A changed property is a change. An
added file is also a change. When you commit the propchange, and the
server does the merge between your rev 7 + propchange and rev 8 (which
is rev 7 + new file), it should either perform the merge and send back a
delta that tells the client that a file was added, or reject the commit
because of a conflict.

If the directory did not change between revs 7 and 8, there's no reason
not to commit the propchange.

I think the current behaviour is a bug -- not in the implementation, but
in the design.

You have exactly the same situation if what you're trying to do is not a
propchange, but adding another file to the directory. But in this case,
we do the right thing:

[brane@SILMARIL s]$ svnadmin create repo
[brane_at_SILMARIL s]$ svn co file:///repo -d foo
[brane_at_SILMARIL s]$ svn co file:///repo -d bar
[brane@SILMARIL s]$ cd foo
[brane@SILMARIL foo]$ touch a; svn add a; svn ci -m ''
A a
Adding s:/foo/a
Committed revision 1.
[brane@SILMARIL foo]$ cd ../bar
[brane@SILMARIL bar]$ touch b; svn add b; svn ci -m ''
A b
Adding s:/bar/b
Committed revision 2.
[brane@SILMARIL bar]$ svn up
A ./a

See? The update after the commit of revision 2 pulls the file out of the
repository. Why should SVN behave differently if revision 2 didn't add a
file to the dir, but only changed a property on the dir?

>This is why we insist on directories being up-to-date when committing
>properties on them. 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.
>
Well, how do we do it in the above case?

-- 
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