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

Re: Behaviour of lock-synchronisation when switching a working copy.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-03-20 19:37:14 CET

Erik Huelsmann wrote:
> In issue 2680, something is called a bug, which I doubt it really is.
> In an attempt to clear 1.5-consider issues, I'm trying to establish
> whether the issue should be rescheduled or closed as INVALID.
>
> The issue is:
>
> - Create a working copy of branch A
> - Lock a file in A (say foo)
> - Switch to branch B
> - Switch back to branch A
>
> Now you'll observe the working copy lost the lock.
>
> maxb and I think in this scenario of 'switch' as a new checkout, only
> more efficient. Which means switching back to A in step 4 is acting as
> expected. In other words we think of the issue as INVALID.
>
> sussman on the other hand says that switch isn't anything other than
> an update. If you look at it that way, how should an update from a
> non-locked resource to a locked one behave? Even though the user
> himself holds the lock, should it be automatically re-acquired? How is
> the working copy supposed to know?

While switch is implemented like an update under-the-hood, I don't think
that means it carries the same semantic meaning to our users.

In most use-cases, switching is an optimization against checking out a new
working copy and applying the local mods from the original working copy to
the new one. Locks aren't local modifications, so it's perfectly fine --
arguably expected, even -- if those get lost when you switch away from the
URL to which they are attached. Still, seems we could somehow do a little
better job here, possibly allowing the user to "steal" his own lock and get
that token into his re-switched (un-switched?) working copy as part of the
switch operation.

Do we need a --reclaim-locks switch to checkout, update, and switch?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Mar 20 19:37:28 2007

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