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.
> - 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
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?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-06-10 17:30:36 CEST