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).
Thanks,
Kylo
---------------------------------------------------------------------
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