"C. Michael Pilato" <cmpilato_at_collab.net> writes:
> On 06/10/2011 05:28 AM, Philip Martin wrote:
>> Working copy locks were per-directory in 1.6 and 'svn status' showed 'L'
>> to indicate which directories were locked. There is currently a
>> behaviour change in 1.7, 'svn status' now only displays 'L' if the
>> directory is "interesting" for some other reason, added, prop-mod, etc.
>>
>> 1.6 clears locks that are not protecting log files, given the chance, so
>> after an interrupted operation status would typically show 'L' for just
>> the directory that had a log file rather than the whole tree.
>>
>> In 1.7 there is generally only one lock per-tree, so if it is present
>> following an interrupted operation, status would probably have to show
>> 'L' for every directory in the tree to behave like 1.6. However the
>> current behaviour means that status will sometimes show nothing for a
>> locked working copy.
>>
>> Is this behaviour change acceptable? What behaviour do we want?
>
> That we decided to show an 'L' at all probably reveals a great deal about
> what we felt was interesting to users, and may serve as a guide in this
> situation. Clearly we felt that folks would want to know when the working
> copy was locked, so let's start there.
My description missed that 'svn st -v' still shows locks, it's only the
non-verbose status that has changed.
>> - the current behaviour, only show 'L' on otherwise interesting
>> directories
>
> In this situation, the 'L' is effectively useless.
>
>> - the 1.6 behaviour, show 'L' on every locked directory which will often
>> be every directory in the tree
>
> This is, if attainable, the obvious best choice because it doesn't
> needlessly break compatibility with prior behavior.
>
>> - something else
>
> I can't recall -- are our locks always of infinite depth? If so, I would
For most people using the new APIs the locks are infinite, but
per-directory locks are available via the 1.6 legacy wc API.
> think it would it be sufficient to report an 'L' for each of the top-most
> locked path(s) within the scope of the status request (regardless of whether
> those things are "otherwise interesting"). Note that that might not always
> be the paths which are actually at the root of the locked tree. For
> example, if 'trunk/A' is locked, but I run 'svn status trunk/A/D', I still
> would want 'D' to report that it is locked. But maybe I don't care to
> explicitly see that 'G' and 'H' are also locked.
>
> Am I making any sense here?
Yes, that's one approach I was considering. How we handle "interesting"
and "boring" subdirs is a problem:
$ svn st wc
L wc
ML wc/A/B
wc/A would appear to be unlocked.
I'm also a bit concerned about performance, but I suppose I should
implement something and measure it. Ideally having found no locks, or
an infinte lock covering the operation root, we would not need to check
the locks table again, but since status is implemented as one
transaction per directorory that's not strictly valid.
--
Philip
Received on 2011-06-10 18:06:29 CEST