[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Projects?

From: Files <files_at_poetryunlimited.com>
Date: 2003-10-22 23:36:33 CEST

The reason I would advocate the ability to do summaries is simple.

It really seems simple to extract verbose amounts of data, to roll up the
quantity when the client library can do the same and transmit less
information.

To me it's the equivalent of being able to do a:

select keyval,count(*) from some_table group by keyval.

We could always layer stuff on top of the library and live in the stone
ages as we did for the older ODBC libraries (conformance level 0 and some
level 1) which did not offer this kind of transparency and the client
performed the iteration. MS-Access to this day still does so.

Personally, I don't enjoy working in an 'MS-Access' like environment.

Or, we could look forward and allow a more expressive summary ability as
part of the client library (a la ODBC conformance level 2 and 3 - I hope I
got those numbers right - I always mix them up).

I could make the same analogy w/ SQL89, SQL92 and SQL3, but I'll skip it
for the sake of brevity.

When I first suggested the --count flag, I had not fleshed out the thought
completely, which is why I was originally advocating a simple counting
utility in a shell script.

The more I think about it, summarization and meta-data extraction, really
isn't a "outside of the box" type activity, except when it happens in
antedeluvium times.

Personally, we are approaching a watershed where these services would be
useful to roll into the main library. Maybe not pre-1.0, but post-1.0
would be a good idea, IMHO.

There is a limit to where your data extraction to perform meta-data
crunching takes a hit, and that point is where you overwork the repository
to come up w/ the answer.

For example, I am working on being able to extract all edge relationships.
If I do it as a direct tool on top of svn, it will be VERY slow. But if I
apply the tool at a lower level and avoid some of the unnecessary data
crunching, the speed gains are significant.

I agree - the plain old --count is probably too limiting in and of itself.
It was just a thought. But I *would* like to see summarization be a part
of the services that subversion permits.

So I guess I agree with you and I disagree w/ you at the same time. :)

Cheers.

Barry Scott said:
> My 2 pence worth.
>
> appropriated tool on top of svn. It would help if they could be clear
> on what the their "interesting" thing is. In other words what is the
>
> I'd hope that the svn log -count does not get implemented as its not
> important for svn's operation.

-- 
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 23:37:24 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.