[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] RFC/preview: automate interface for cvssync
From: |
Christof Petig |
Subject: |
Re: [Monotone-devel] RFC/preview: automate interface for cvssync |
Date: |
Mon, 31 Jul 2006 09:00:56 +0200 |
User-agent: |
Thunderbird 1.5.0.2 (X11/20060521) |
Timothy Brownawell schrieb:
>> *) The information attachment is meant to be space efficient (xdiff
>> encoded where possible) and uses both special files ".mtn-syn-*" and
>> certificates where it has to attach information to an already present
>> revision.
>
> Why is there a need for this? It seems like it would be about the same
> as having a XXXXXXX-metadata branch for the revision, except without
> being able to use our existing merge infrastructure when people change
> the metadata in different ways.
The requirement is simple: Attach some information (which should get
delta encoded for space efficiency) to an already existing revision.
The upside of using certificates: The data is directly associated to the
correct revision and gets distributed with it. Con: You cannot easily
remove metadata (Removing all certificates of a certain type is possible
locally)
Using a different branch: Con: You have to additionally specify which
revision your metadata is equivalent to. You have to handle multiple
heads etc. Pro: You can easily edit the metadata and need not share it
with others.
I decided against using a different branch, it is possible though (and
the change is mostly transparent to cvssync - due to using the automate
interface).
As present you dont have to merge metadata, you can as well delete or
garble it on merges without affecting cvssync [which is by design, I
would never trust a user/program to _correctly_ handle metadata on
merges (at least for cvs)]
Christof
signature.asc
Description: OpenPGP digital signature