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