[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: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2004-10-13 20:23:51 CEST

On Wed, 2004-10-13 at 13:09, Jim Correia wrote:
> On Oct 13, 2004, at 1:40 PM, Mark Phippard wrote:
> >> 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
> > automatically.
> Possible unexpected side effects:
> 1) Person gets a lock to edit something in the file, but as a side
> effect of the update that thing has changed. I suppose this could be
> mitigated by telling the user the file has been updated.
> 2) I want to get a lock on FOO to make an edit. svn lock FOO updates it
> to a newer revision. The newer revision also has other files in it,
> some that changes in FOO depend on, but svn lock has put my WC in an
> inconsistent state that breaks the build. If I was told I was out of
> date, and did the single file update myself, I got what I deserved. I
> could also decide if now was a good time to do an svn up and deal with
> the consequences.


We could always have a 'svn lock --update' switch.


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