subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Mohr <a...@lisas.de>
Subject Re: Feature Req: sorthand urls for branches/tags in CLI
Date Sat, 24 Aug 2013 06:13:30 GMT
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.

Mime
View raw message