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

Re: Revision graph rewrite

From: <Stefan.Fuhrmann_at_etas.de>
Date: 2007-07-10 18:46:31 CEST

Stefan Küng <tortoisesvn@gmail.com> wrote:
> > * Use the log caching data structures to represent
> > the data (if l.c. is disabled, collect the data in a
> > temporary container). This will simplify and speed
> > up path operations while reducing memory consumption.
> There seems to be a slight problem with that. I've enabled the cache.
> Then I created the test repository
> (
> Started the revision graph on /trunk of that repository.
> I then get an assertion inside the Subversion lib about the passed path
> not being canonicalized.

For the root folder, the URL passed to SVN had a trailing "/".
This is fixed on /trunk with r10063.

> > * Simplify the algorithm that draws connections.
> > Plain curved lines (Bezier splines) are in most
> > cases well to tell apart and if they should cross
> > a node box, the latter will still be readable.
> > If a denser node placement is defined in future,
> > we may of course add a more sophisticated
> > routing scheme.
> While I like the bezier lines, they're currently too simple. I get way
> too many lines drawn over the nodes. See attached image.

I admit that in your example, there are many of those
instances. However, they can sill be recognized and
told apart.

For large trees, IMHO, the default layout is of little
use whether it uses beziers or straight lines. I attached
one example of what I get at my office with /trunk code
as well as one for the new code. That second image used
a different layout strategy. Both show the graph of
the main project's /trunk.

So, my point is, for non-trival graphs you need a whole
bunch of knobs and switches to tune it into something
itelligle. HEAD of my branch features a some of those
and the results are quite promising. Again, that's IMHO.

> The graph looks good. But why are you drawing it with the lowest
> revision at the top? It's 'backwards' that way. The important part of
> the graph is IMHO the latest revisions, not the earliest. And the
> important stuff should be on top.

Added a switch for that. Actually, it is simpler to
do it that way and at least ClearCase and CVSgraph
use a similar layout. So, I kept the option and turned
it off per default.

> It also seems to me that it is still very unstable. All the graphs I
> tried didn't work at all (at least at first): I got an assertion every
> time. Even for the TSVN trunk I got an assertion. And that one I
> couldn't get to work by fetching the logs for / first.

Sorry for that! There was a nasty double-deletion problem
(r10025) along with a few simplier issues (r10020, r10021).

So, now I would like to ask you to give it a second try ;)

-- Stefan^2.

To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org

Received on Tue Jul 10 18:46:04 2007

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

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