[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconvenience

From: Markus Schiltknecht
Subject: Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?))
Date: Sat, 09 Sep 2006 09:58:45 +0200
User-agent: Thunderbird (X11/20060812)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]