Stefan.Fuhrmann@etas.de wrote:
>
> *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
> >
> (http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/test/BuildRevisionGraphTestRepo.bat).
> > 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.
I had to remove the existing cache first, but then it worked.
Thanks!
>
> > > * 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.
Nice switches you've added there! :)
I think we could maybe try to use S-beziercurves sometime later. For
now, I think it is good enough.
> > 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 ;)
Looks very good. Would you merge this back to /trunk so others can give
it a try too?
The only thing that doesn't work right now is the path filter, but I
guess that's not much of a problem to get working again.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jul 10 20:59:49 2007