On Fri, Aug 23, 2013 at 10:55:03PM +0200, Branko Čibej wrote:
> On 23.08.2013 21:34, Daniel Shahaf wrote:
> > 'svn list-branches' would work how?
>
> About the same as "svn mergeinfo"? Or how about a variant on "svn
> status" that also looks for that prperty? Frankly, I find this problem
> infinitesimally small compared to the ones I mentioned in connection
> with the proposal given in this thread.
>
> Indexing based on the presence and/or value of a property is a somewhat
> orthogonal feature, IMO, but there's been a lot of interest about that
> as well (e.g., what did user X commit? sure, you can filter 'svn log'
> but that's kinda slow). If/when it appears, "svn list-branches" could
> use it. Until it does, we already more than one command that crawls the
> whole working copy or repository tree. This one is no different.
Perhaps it would be worthwhile to have extended ops be implemented
by a helper binary for such extended purposes ("svnstat"? "svnanalyze"?).
That way one would not bloat the usual hotpath workhorse binary with such...
shenanigans :)
(both in performance terms and in usability terms - usage text length...)
But that decision probably depends on the total number of conceivable
"extended" ops. If there's only few high-level op names
which do all the work and options internally,
then one could keep them provided by svn, else...
But keeping them in main binary might still influence overall performance -
unless implementation data of commands
(as possibly opposed to registration data of commands!)
is being provided on-demand only anyway, via shared library dlopen references.
OTOH you could argue that the total amount of SCM sub commands will ultimately
remain limited, thus it's better to keep them aggregated to main binary
and do maximum optimization of that case instead (dlopen etc.).
E.g. git (Jehovah! ;) seems to be doing it that way, and with
external git_load_dirs binary being analogous to svn_load_dirs binary to boot.
Apologies for the long rambling - I had expected it to remain shorter,
but then with all the details added...
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
Received on 2013-08-24 08:14:12 CEST