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

[Markus Schiltknecht]

Daniel Carosone wrote:
> Nope. It doesn't really change from one revision to the next, does it?

Uhm, right, that's yet another case. But that would need 'per branch' or 
even 'per repository' attributes, which we don't have. But there are CVS 
informations which change per revision.

> At least, we want to inherit the same CVSROOT from one revision to the
> next until there's a need to change it (because the server moved).

I'd set all the CVS import stuff to 'once-off' attrs (that don't get 
passed to children) to avoid confusion. Having said that, of course the 
importer needs to explicitly set the attrs for every child revision.

> I'm not sure what you mean by "revision attributes". There's no such
> thing, now: if you want to annotate revisions with extra information,
> you use certs, and can do so after the fact.

No, certs are not delta-compressed... that's too inefficient as pointed 
out by Nathaniel.


Let me try again to explain what I mean. A CVS import gives a lot of 
information about it's files, it's faked 'revisions', it's branches and 
it's repository. AFAIK we discussed along the lines of storing somewhat 
them like that:

attr:                  sample value:          attr of:

cvs:file-revision       1.6                    per file
cvs:root                :address@hidden           per module
cvs:module              monotone               per module

I would also add the following:

cvs:revision_start      "02/07/1997 13:41:05"  per revision
cvs:revision_end        "02/07/1997 13:41:12"  per revision

If possible and for revisions for which this applies also:

cvs:revision_conflicts  [e6a903d31...]         per revision


So we have three things for which we have to store CVS information: 
files, revisions and modules.

I completely agree that it does not make sense to invent 'per module' 
attributes, because those can easily be stored in the manifest. Thanks 
to delta-compression that's quite efficient.

But 'per revision' and 'per file' attributes can easily be stored in the 
manifest. 'per file' attributes can be attached to their files, as we 
have file attributes in monotone.

My question was: can we have 'per revision' attributes, which are not 
necessarily attached to the root directory. Because it's not an 
attribute of the _directory_ in the sense that the root directory has it 
while sub-directories don't. But it's an attribute of the complete 
revision. I must admit it's more a philosophical question about where 
things should go than a technical one.

But I suppose it would be trivial to implement: add attributes to the 
manifest, which are not necessarily bound to files or directories. Don't 
we have such a thing already?

Please also remember what the CVS import information should be good for:
 a) for users to be able to determine where a revision came from.
 b) for later resyncs to determine what has been imported and what not.

From a users point of view, it seems confusing if one has to get the 
root directory's attributes to get the revision attributes, IMO.

Regards

Markus