[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking UI comments

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-16 05:59:25 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.