On Mon, Jun 23, 2014 at 2:08 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Jun 23, 2014 at 01:55:32PM +0200, Branko Čibej wrote:
>> There's a world of difference here. The former is an error that prevents
>> you from using the working copy. The latter case doesn't prevent anything.
>
> This discussion is about a performance issue, not a behavioural one.
>
>> BTW, don't you find it a bit strange to get error (or warning) messages
>> from our libraries that refer to the implementation of our command-line
>> client?
>
> That doesn't sound at all like what Johan is asking for.
>
> If status information returned by the library to clients said "the timestamp
> of this node doesn't match the recorded one" clients could then deal with
> this in any manner they wished.
Indeed. BTW, I just copy-pasted the error / warning that you get when
you run into working copy locks (that warning explicitly mentions 'svn
cleanup'). I don't know if this warning comes from the library or from
the command line client. If the former, then I agree it's not ideal as
it is.
Another suggestion in this context: a '--report' option for 'svn
status' would also be some help for users (or their administrators) to
diagnose (performance) problems. It could generate a more extensive
report of the state of the working copy, including the amount of
mismatching metadata.
Anyone who has done 1st line support for svn users for a while already
knows the phrase: "try running 'svn cleanup' and see if the situation
improves", but it's always a shot in the dark when users complain
about svn performance. Right now there is no (simple, free,
ubiquitous) tool that can report on the amount of metadata-mismatch.
You just have to guess (or perform some kind of clever query on wc.db
yourself ...(?)). Would be nice if one could just say "run 'svn status
--report' and send me the report, so we can see what's causing the
problem".
Maybe that's a kind of tool that doesn't belong in core svn (but OTOH,
if users have to download/install a separate tool for this, they
probably won't), but anyway, putting it out here.
--
Johan
Received on 2014-06-23 15:04:31 CEST