On Mon, Jun 23, 2014 at 2:08 PM, Stefan Sperling <s...@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
