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

[Christof Petig]

Markus Schiltknecht schrieb:
>> 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.

That was added for cvssync to recognize a locally* changed file (like
what cvs does with timestamps). Of course that is unnecessary for
anything else.

*) locally means within a monotone network - to the cvs server this
looks like a single client

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

This map was intended to solve the branch rooting problem, it cannot
help to construct revisions from rcs information. Actually finding a
root would mean to intersect ("Schnittmenge") the lists for every
pair<path,revision> of the branch point (likely the revision number
minus the last to numbers).

If the intersection is empty the branch point is not a valid revision
and the branch cannot be rooted. (You can create a situation like this
by moving a tag for a single file and creating the branch starting from
this tag.)

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

I also use a map<modified_timestamp>, vector<pair<path,rcs_revision> > >
to construct the revision tree. That is the most naive solution which I
plan to replace by something else once problems arise (for me they
didn't yet).

modified_timestamp means: try to group matching changelogs (within a
given time period) and split at differing changelogs. Newer cvs
revisions have a checkin id! I see some on my ubuntu edgy (unstable)
machine.

   Christof

signature.asc
Description: OpenPGP digital signature