Re: [Monotone-devel] Re: cvsimport branch reconstruction status

[Markus Schiltknecht]

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