Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)

[Markus Schiltknecht]

Hi,

Nathaniel Smith wrote:
 > There is a branch called .cvsimport-branch-reconstruction which
> attempts to do this.  It hasn't been merged or anything, because
> everyone was too cowardly to figure out how it was supposed to work
> and whether its approach was plausible or not :-(.

Yeah, and I'm still working on it. I only have very limited time for 
that, though.

> I ported it forward to current mainline a week or two ago (had to port
> the tests, mainly), and it seems to have bit-rotten slightly -- its
> branch tests are failing, but in ways that make it look like it's
> _really close_ to correctly reconstruction the branches.  There are
> probably just some stupid bugs.

Thanks for that! I was already wondering why those worked so well...

> If anyone can figure out how to make it pass its own tests, then we
> can merge it into mainline, probably as an optional feature for now.
> (The idea would be that since CVS is so horrid, there will certainly
> be repos that at first we fail to reconstruct branches on.  We want
> the functionality in mainline so that we can discover which repos
> those are, but we don't want to leave people with such repos stuck,
> either.)

Well, the main critique point was: it's not close enough to cvs2svn.

I have read the design-notes.txt of cvs2svn (which is a very good 
documentation of their process, BTW) and came to the conclusion that we 
cannot rely on the timestamp of the file revisions. Thus I began 
implementing a file_id -> RCS revision number mapping. I've currently 
just added a table to do this. Having that information stored durably 
allows for a faster resync later on, I think.

Regards

Markus