Patrick Smears <patrick.smears@ensoft.co.uk> writes:
> On Tue, 16 Nov 2004, Niels Skou Olsen wrote:
>
>> "Dale Worley" <dworley@pingtel.com> writes:
>>
>> > This is a side-effect of one of the weirder aspects of Subversion: When you
>> > check out a tree, it is at, say, rev 1, and all the directories and all the
>> > files have BASE = rev 1.
>> >
>> > Now say you check in a new file. That new file now has BASE = rev 2. But
>> > the directory containing it is still at BASE = rev 1, because you didn't
>> > change it. But when you do an update, the directory is updated to BASE =
>> > rev 2.
>>
>> If you add a new file to a directory you have indeed changed the directory!
>> So with your example I would expect that, after the commit, if the new file
>> has BASE=r2, then the directory it was added to must also have BASE=r2.
>
> That seems fair enough in the simple case. But consider what happens if,
> before you commit, another developer adds a different file to the
> directory - so your commit is now r3.
But in that case shouldn't the commit fail because the working copy is out
of date? The last one to commit must then update and check that everything
is ok, and then commit again. Isn't that the normal procedure for resolving
commit conflicts?
> If the directory in your WC were marked BASE=r3, that would imply that the
> new file that the other developer checked in was also in your WC, which it
> isn't...
Correct, and to prevent this the commit should fail with an out-of-date
error.
> I agree that it's counterintuitive in the case where there's only one
> developer, but when multiple commits are going on at the same time, it's
> the only consistent way (that anyone can come up with) to behave...
If the add+commit succeeds before any other developer has done a commit to
the same directory, then it must be safe and correct to update the BASE
rev.
Best regards,
Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 16 18:07:16 2004