[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: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-13 19:40:27 CEST

Jim Correia <jim.correia@pobox.com> wrote on 10/13/2004 12:00:25 PM:

> On Oct 13, 2004, at 9:23 AM, Mark Phippard wrote:
> > I do not really understand the objections here. If you have to have
> > an up
> > to date file in order to lock it, and we are trying to make this easy
> > for
> > "users", then why shouldn't svn lock update the file automatically?
> Because it couples unrelated operations and may have unexpected results
> for the user.

I haven't seen a good explanation as to what those unexpected results
would be. If the file were locally modified, I do not think anyone is
suggesting that svn lock should do an update, this is actually the so
called "hijack" scenario. So other than that, given that you have to be
up to date to acquire the lock, what would be unexpected about doing it

> Committing a delete of an out of date file returns an error. I see no
> reason why trying to acquire a lock on an out of date file should do
> the same.

I guess I just see it as more work that in order to lock a file, a user
has to run 2 commands. That being said, I will confess that having read
more messages in the thread, I am now realizing that the user doesn't have
to be at HEAD in their working copy, they just have to have the latest
revision of that file, as with commit. I suppose that really isn't that


Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 19:40:53 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.