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

Re: "svn commit" performance

From: <cmpilato_at_collab.net>
Date: 2003-06-23 17:51:04 CEST

Greg Stein <gstein@lyra.org> writes:

> Sounds like we have to stop the "parse path/url arguments without context"
> stuff that's been going on. Seems like we run into a bug every now and then
> where we've been trying to handle some arguments without truly knowing what
> the heck they represent.
> Assuming some level of agreement, then the next question is: how to get the
> right amount of context into the path condensing? Before each path can be
> condensed, it would almost seem there is a question: can I combine >these<
> two paths together? Some kind of a callback would have to say "woah! no,
> those are separate WCs"
> Of course, if our committing code traversed mixed-repos WCs, then we could
> go ahead and allow the pathes to be condensed without worry.

Actually, my thinking led the opposite direction -- let's just stop
altogether removing redundancy up front from the set of input paths.
If we instead teach our tool to quickly recognize redundant targets as
we are processing them deep in the code, I think we'll be in much
better shape.

We can still do things to optimize this. For example, for commits
(and other operations where the order of targets doesn't matter) we
can sort the targets in a depth-first order. This way the largest
portions of the WCs get locked up front, which makes redundant input
in those working copies easy to spot (we'll be able to get the
adm_access baton from an existing set).

Anyway, just spouting off ideas with no code to back them yet.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 17:51:01 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.