Jack Repenning wrote:
> The idea of "consistency" that leads you to propose this change is
> myopic and pedantic. "Consistency" of user experience operates as a
> sort of average over many axes: within the command set, over history,
> within the work flows, etc. The idea that update can, like checkout,
> change the depth is entirely consistent with the user experience, and
> apparently (given that it was the initial implementation) with at least
> Karl's hind-brain as well (not to mention my own).
I've had some time to think about this, and realize where my logical error
was: compatibility.
I placed some priority on allowing 'svn update -N' and 'svn switch -N' to
continue meaning exactly what they do today. But I'm not sure the effects
of those operations are use-cases worth preserving, and suspect they exist
only as artifacts of a previous deficiency in Subversion.
Why do we have 'svn update -N' today? Probably because 'svn checkout -N'
was non-sticky. Same for 'svn switch -N'. I think we all would agree that
if 'svn checkout -N && svn update' would have worked as expected, only
updating the items already present in the shallow working copy which
resulted from the checkout, we'd have no real need of a -N flag to update or
switch.
So, recognizing what I believe to have been a misstep in the past with the
introduction of -N flags to 'update' and 'switch', and standing now
unwilling to preserve their prior meanings even at the risk of making an
incompatible change, I officially recant my suggestion that 'svn checkout
--depth' affect change on an existing working copy, and further suggest that
'svn update --depth' and 'svn switch --depth' handle that task, telescoping
working copies both more deeply and more shallowly as indicated by the
requested depth.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Oct 1 20:46:35 2007