Re: Commit bug?

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

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org