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

[Markus Schiltknecht]

Christof Petig wrote:
> a file_id RCS revision table would be 1:N and is as such perhaps a bit
> inconvenient ...

Yes, I see... hm...

> cvssync2 adds a file (called .mtn-sync-cvs which contains (more than) a
> table of ( revision[/keyword_substitution] path file_id ) per revision
> to store that information (easily delta encoded and distributed this way)).*
>
> I would be happy to have any rcs_revision information available from a
> cvs_import!

Yes, adding ( RCS-Revision, file_path ) per revision to a cert would be 
great. I don't think file_id should be in there again.

> Perhaps storing that information and building a
> map<pair<path,rcs_revision>,list<revision_id> > from all known revisions
> to determine the branch point is a good idea. Since searching branch
> roots should be a seldom operation performance is not critical and you
> should be able to build the table afterwards.

Hm.. I don't really get my mind around that map, currently. However, I 
don't only need to get the branch root, but I also have to be able to 
determine the order of the file revisions by RCS version (instead of the 
date, as it is done now).

But maybe that can be done before, correcting the date. And this is also 
irrelevant for later resyncs...

I need to think more about it.

Regards

Markus