On Thu, 30 Oct 2003 14:36:48 -0600, kfogel@collab.net wrote:
> Philip Martin <philip@codematters.co.uk> writes:
> > I am still uneasy about the whole idea of having read locks convert
> > into write locks. It takes away my ability to be sure that an
> > operation is read only. Suppose some operation doesn't work the way I
> > expect, how do I investigate it? Simply running 'svn status' might
> > change the working copy. I might have to start using two usernames,
> > one without write access!
>
> I'm not as uncomfortable with it as you are. I guess I started out
> from the point of view that managing the working copy is Subversion's
> business -- any Subversion operation can do whatever it feels is
> appropriate to make things work nicely. We developers are used to
> thinking of 'svn status' as read-only, and now we're considering it as
> read-write, only because we're aware of the underlying implemention of
> .svn dirs and lockfiles. None of that stuff matters to the user.
> They'll just be happy if things run faster.
Well, I'm just a humble user, but that's who UIs are for :) Anyway, it seems
more logical to me to put WC fixup operations in 'svn cleanup'. It can be
documented in the book/online help; 'Over time, timestamps in your WC may get
out of date, and stuff will slow down. Run svn cleanup to fix.'
It seems possible that as time goes on, other fixup operations may be needed in
the WC. Then you can say in general, 'If your WC seems screwy, run svn cleanup
on it.' I also think that this approach would look cleaner from a programming
standpoint, i.e. lumping all cleanup operations together in one place rather
than having them scattered over several subcommands.
--
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 05:18:13 2003