|
From: | Markus Schiltknecht |
Subject: | Re: [Monotone-devel] Re: cvsimport branch reconstruction status |
Date: | Fri, 13 Oct 2006 22:04:27 +0200 |
User-agent: | Thunderbird 1.5.0.7 (X11/20060927) |
Hi, Graydon Hoare wrote:
I'm confused then. The old code already does this (and reconstructs branches). I thought you were just working on an improvement to the branch-reconstruction algorithm.
Did you read the cvs2svn 2.0 algorithm proposal? I think the main difference to the current trunk cvs_import algorithm in monotone is that it does not use timestamps to figure out dependencies between revisions.
Instead during collection, dependencies (of the singe cvs events) are recorded. Afterwards, a topological sort takes care of respecting these dependencies on a per-blob level.
I'll try to take some time to review it.
I'd greatly appreciate that.
I'd prefer you didn't, but I suppose it's sort of a case-by-case thing. It's a hefty compile-time requirement, and the code to interface with it isn't pretty.
I currently have a 'revision_iterator' which gets the revisions one-by-one, feeding it into the cluster_consumer. Those two classes could even be merged together, since the assignment operator of revision_iterator mainly calls 'consume_cluster'.
I agree that the interface isn't exactly pretty, but it couples quite well with the cluster_consumer.
My reasoning for using boost was: I didn't want to write a topological sort algorithm, boost is already used by monotone and I realized to late, that there is a graph.cc :-)
But even now, I think I'll stick with the boost one until I know exactly what type of graph performs best. For example I'm still unsure if some branch splitting logic needs edges to be connected both ways. Not to mention all the exact parameters for the adjacency_list<...>.
Once we've settled for a graph type and algorithms to use, I'm more than happy to try to integrate it with existing code and/or write our own, optimized variant.
Regards Markus
[Prev in Thread] | Current Thread | [Next in Thread] |