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

[Christof Petig]

Daniel Carosone schrieb:
> On Wed, Aug 23, 2006 at 08:47:55PM +0200, Lapo Luchini wrote:
>>> cvssync and cvs_import do not mix (yet) since cvs_import does not
>>> remember the corresponding cvs revisions for each file.
>> I think adding a certificate with the corresponding CVS revision would
>> be a *good thing* whether one wishes to update the import or not: it
>> probably occupies very little in the DB and helps reply to questions
>> like "what revision contains file xyz version 1.254?".
>> I guess the main problem is that certificates are per-revision and not
>> per-file, so yet another "blob" of data to be parsed would be needed
>> (with similar speed issues as "annotate" has, I guess).
> 
> I think I recall suggesting previously that this information might
> well be stored in CVS/Entries files within the monotone repository.

That's your Sat, 17 Dec 2005 09:24:29 +1100 message.

I recall to try it and dump it in favor of a .mtn-cvs-sync. And I
thought I had written it down somewhere or to the list (but can't find)

------------- >8 --------- (not the real reason but sensible)
Reason was that I need a way to tell which revision is the last one
known to CVS. I assume that a changed .mtn-cvs-sync file means that a
synchronization happened. This way I can avoid to introduce yet another
certificate just for the purpose of marking synched revisions. With
.../CVS/Entries I would have to check a file in every directory to tell.

Relying on timestamps (which are used within Entries) might not be a
good idea with a sha1 based _distributed_ VCS to tell whether I file is
changed (regarding to the last recorded CVS revision).

Also since monotone is revision oriented and CVS file oriented there are
numerous ways for them to get out of sync (as seen by whole tree
revisions), just try an update in a single directory.

Well. My decision was mostly driven by simplicity, robustness and
user-invisibility. It is definitely possible to store the information
from .mtn-sync-cvs within CVS/Repository CVS/Root and CVS/Entries.
-------------- >8 -------------- (enlightenment happens)

I have to change the synchronisation information on push (monotone
commits into CVS) and I cannot change the contents of files of an
existing information. Thus I wanted to avoid a mechanism which looks to
work well with using cvs on the tree directly ... unless you actually
commit changes done in monotone to cvs.

This does not apply to pull and cvs_import. But having incorrect
CVS/Entries (by a push) is worse than having none at all.

A script might be able to create the */CVS/* structure by parsing the
most recent (.mtn-sync-cvs + certificate deltas) on the fly, but I don't
want to put */CVS/* under revision control.

> This way, you can basically use a monotone checkout of an imported cvs
> revision as a CVS revision. As well as helping users switch, this
> probably helps testing that the import worked correctly, too.

Agreed. Unless you ever ever push back modifications.

>> I look forward trying it as soon as you give a thumb-up ;-)
> 
> me too.  I can't really help development much, but if there's any way
> encouragement will make a difference, let me know.

words like this help much (I actually get the impression of spending my
nights on a feature which is used by someone)

>> Does it still apply to cvs_import? Does it apply to cvs_sync (and/or
>> will apply to your "complete redesign"?)

The redesign does not touch branch logic or revision reconstruction at
all. It only changes the backend: Instead of linking to monotone, the
new mtn_cvs uses the automate interface to synchronize between cvs and
monotone.

   Christof

signature.asc
Description: OpenPGP digital signature