On Fri, Sep 08, 2006 at 06:50:28PM +0200, Markus Schiltknecht wrote: > Christof Petig wrote: > >that's the root, isn't it. The server path is in the file Repository. > > Right, it's the CVSROOT, sorry. > > > actually the last plan was to store it as an attribute called > >"cvs:server_path" attached to the root directory "". > > ISTM that it's not an attribute of the root directory, but of the > revision.
Nope. It doesn't really change from one revision to the next, does it? 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). > OTOH what else is needed to add revision attributes? Only little more > text in the manifest, isn't it? 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. If this doesn't match what you meant, think about it this way: is there a use case you have in mind where this information must be part of the revision (set at creation time, and part of the hash that makes up the revision id) but makes no sense on the root dir? Or is it that you want once-off attr's that don't get passed on to children? We might imagine uses for those, but why would we restrict them to the revision as a whole rather than allow them per file? Remember that attr's are just values; interpretation of those values is a matter of convention and implementation *per attribute*, as in previous discussion where I suggested refining the interpretation of the cvs version attr to be 'the rev we last synced with' rather than strictly 'the rev we are in sync with'. -- Dan.
pgpGK2rBzW03f.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel