Re: [Monotone-devel] temporary attributes, cvssync
* Christof Petig:
My requirements are very simple: I need to attach a list of {CVS
revision per file} to an existing revision.
Do you need to attach this information to the *revision*, or to a
specific version of a file?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] temporary attributes, cvssync
Florian Weimer schrieb:
* Christof Petig:
My requirements are very simple: I need to attach a list of {CVS
revision per file} to an existing revision.
Do you need to attach this information to the *revision*, or to a
specific version of a file?
Neither ;-)
Attaching the information to a version of a file is not enough since a
file version might have several CVS revisions pointing to it.
And attaching to a revision unnecessarily duplicates information (few
files change per revision). But delta encoding should handle that. So
since revisions are monotones main objects, it's easiest to attach the
information to them.
Christof
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] temporary attributes, cvssync (was Re: What are rosters)
On Tue, Nov 22, 2005 at 09:01:48AM +0100, Christof Petig wrote: The only additional feature I missed when I developed cvssync was to attach a file (or some sort of long text) to an already existing revision. So if you'd ever come near to think about a feature like that it would greatly help cvssync. [At the moment I use a fragile delta encoded certificate chain to store cvs revisions and keyword expansion] Rosters don't help with that; attributes are still integrated into the immutable hashed data. I'm not sure what would... the cert chaining thing just doesn't feel right, but... it seems like what we want is, umm, file attributes that go away when a file is edited, or something. Would that be an elegant solution? Does it have enough semantic justification to integrate into monotone? (I literally can't tell either way, it rings both my hmm, sensible and gah, are you crazy? intuitions at the same time.) It would be sort of like a cleaned up file cert, but falling on the data side of the big data/cert divide. (yes, at the moment I am more using cvssync (ten times a day on average) than developing it) Cool. I would still very much like to get it into a release so that other people can play with it... I'm sorry I've lost track of the status with all this roster stuff and all! I'm guessing it won't take a huge amount of work to convert cvssync over to rosters (graydon did cvs_import in a few hours), but I don't know. Random thought: perhaps someone who has done more work on mainline would like to be deputized to shepherd cvssync in? Since I keep not having the time and being distracted by other things? -- Nathaniel -- But in Middle-earth, the distinct accusative case disappeared from the speech of the Noldor (such things happen when you are busy fighting Orcs, Balrogs, and Dragons). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] temporary attributes, cvssync (was Re: What are rosters)
Nathaniel Smith schrieb:
On Tue, Nov 22, 2005 at 09:01:48AM +0100, Christof Petig wrote:
The only additional feature I missed when I developed cvssync was to
attach a file (or some sort of long text) to an already existing
revision. So if you'd ever come near to think about a feature like that
it would greatly help cvssync. [At the moment I use a fragile delta
encoded certificate chain to store cvs revisions and keyword expansion]
Rosters don't help with that; attributes are still integrated into the
immutable hashed data.
I'm not sure what would... the cert chaining thing just doesn't feel
right, but... it seems like what we want is, umm, file attributes
that go away when a file is edited, or something. Would that be
an elegant solution? Does it have enough semantic justification to
integrate into monotone? (I literally can't tell either way, it
rings both my hmm, sensible and gah, are you crazy? intuitions at
the same time.) It would be sort of like a cleaned up file cert, but
falling on the data side of the big data/cert divide.
My requirements are very simple: I need to attach a list of {CVS
revision per file} to an existing revision. Abusing recursive certs
never was the best idea and storing them fully per revision just takes
too much space.
IMHO the best would be a cert which says you can find my contents in
file 0123456 and which would be maintained over netsync (indirection
certificates?).
Random thought: perhaps someone who has done more work on mainline
would like to be deputized to shepherd cvssync in? Since I keep not
having the time and being distracted by other things?
I'm not opposed to that at all. I simply don't see anybody stepping
forward ;-) .
Christof
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
