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

[Christof Petig]

Markus Schiltknecht schrieb:
> Markus Schiltknecht wrote:
>> 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.
> 
> I've just synced my changes to venge.net. Please be aware that the code
> currently is quite messy. The branch point detection code relies on the
> timestamp, which is surely wrong.
> 
> I'll try to clean it up somewhat as soon as possible.
> 
> Regarding RCS revision number: saving all RCS numbers of every file in a
> revision in a cert is fine, but I need to be able to get the number for
> a file_id. Is it okay to have a SQL table for that? What else would be
> feasible?

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

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)).*

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.

I would be happy to have any rcs_revision information available from a
cvs_import!

Any thoughts?
   Christof

*) As you cannot attach files to existing revisions cvssync uses certs,
too, to mark an already existing revision.

signature.asc
Description: OpenPGP digital signature