[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 1.5.0.5 (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.
Regards
Markus
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Nathaniel Smith, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)),
Markus Schiltknecht <=
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Thomas Moschny, 2006/09/08
Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08