[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 (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

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

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)]


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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