Ben Gollmer wrote:
>>.svn dirs and lockfiles. None of that stuff matters to the user.
>>They'll just be happy if things run faster.
I'm +1 to fixing things on the fly, because I think it's the best thing
to do from a users point of view. If on the other hand it 'breaks'
subversion to turn read-only operations into read-write, I've got a
suggestion to make, see below.
> 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'.
That is the best place to put them, no doubt.
> 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.'
Are you sure, this is going to work. Users will complain about
subversion being slow and not read the book...
> 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.
Hi Folks,
I see another viable solution here. If a(ny) svn operation detects some
'screwyness' in the WC it can report something like 'WC (screwed |
timestamps out of date | locked). run svn cleanup'.
This way status et al. wouldn't have to turn into a read-write operation
and everything could be bundled together in svn cleanup.
But - there's always a but :-)
I don't know how fast working copys degrade over time, so I have no idea
how likely this is to happen. If after every second svn command the user
would be prompted to run cleanup, then I stongly advocate fixing
timestamps on the fly.
Cheers
-Lübbe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 08:54:52 2003