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

Re: Revision graph functionality?

From: Kylo Ginsberg <kylo.ginsberg_at_gmail.com>
Date: 2007-03-23 15:32:22 CET

On 3/23/07, Rajko Albrecht <ral@alwins-world.de> wrote:
> Am Freitag, 23. März 2007 schrieb Ryan Schmidt:
> > I don't know if any of the existing tools do this, but it sounds to
> > me like it should be possible for a post-commit hook to record
> > relevant information about the commit in a database, and for a
> > revision graph maker to query that database more quickly than
> > querying the repository directly.
> >
> > I don't have experience with revision graphs... what does one look
> > like? Can you send me a sample?
> http://www.alwins-world.de/wiki/programs/kdesvn/ScreenShots, the last image is
> such an example, too.
> The problem behind is: you must fetch it. With my tests with kdesvn it shows,
> the most time costs the fetch. Parsing that bunch of revisions isn't a
> problem. I'd somettimes tried for testing generating a graph of a item in dke
> repository with at this time more then 500k entries, this is impossible. You
> have wait hours getting all logs.

Yes, this was my understanding -- the log retrieval time is where most
of the time is spent.

> So, what would help: a log-call where only log entries belonging to an item
> existing at a specific revision would send.

Can you elaborate? Do you mean an svn log command which would show
not just ancestry, but descent and "cousins" for a given file? That
is quite literally what one wants, but I'm not sure if that's what you
mean or something else?

>TortoiseSvn and kdesvn must get
> the whole log, parsing it twice (from newest to oldest and back) to detect
> copies/moves and so on.

Why parsing it twice? Once, newest to oldest to find the root parent,
then back from the root to find all descendents?

> When only getting a specific subset of log....

Does this sentence end: "it would be much faster"? Of have I missed your point?

> Hooks into a database isn't real usable for both clients, 'cause them have to

Agreed, not a solution that would support multiple clients (unless it
exposed its own api, but this could be prohibitively elaborate).


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 23 15:32:53 2007

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

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