Daniel_Patterson@national.com.au wrote:
>
>
>Branko Čibej <brane@xbc.nu> wrote on 10/15/2004 09:00:12 AM:
>
>
>>I think svn should behave exactly as with "normal" conflicts, _except_
>>that it should not try to merge changes into the working copy --
>>regardless of whether the working copy has actually changed from BASE.
>>For UI purposes, we could show an H(ijack) instead of a C(onflict), but
>>the same information may well be conveyed by "svn st" marking the file
>>as locked in the WC.
>>
>>
>
> What about the race condition where you've not yet added the
> svn:lock property to a file (i.e. it's decided to convert
> some file to use locking after it's been there for a while)?
>
>
IMHO a hijack has nothing to do with the svn:(must-)lock property. That
only defines whether the server will allow you to commit changes without
holding a lock. A "hijack" is defined as "someone changed a file that I
have locked".
> Consider:
>
> 1) File dir/file has no svn:lock
> 2) User A and user B do "svn co" to populate their WCs
> 3) User B sets the svn:lock property on dir/file,
> in the meantime, user A starts editing dir/file.
> 4) User B does "svn update ; svn lock dir/file"
> and is given a lock.
> 5) User A tries to commit their changes. They recieve an
> "out of date" error, so they run "svn update".
> What happens now?
>
>
User A does not hold a lock on the file, therefore the upstream changes
will be merged into the WC; but A won't be able to commit without
locking the file first. As far as I'm concerned, svn :must-lock does
_not_ mean that the file is not mergeable.
> Has user A hijacked the file, or is it a conflict?
>
>
As per my definition above, nobody has hijacked anything.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 16 05:59:35 2004