monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] long RFC: "contexts"


From: Jon Bright
Subject: Re: [Monotone-devel] long RFC: "contexts"
Date: Thu, 27 May 2004 13:32:23 +0200
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

Christof Petig wrote:

I was not quite sold to context IDs (which simply adds _another_ unique ID for hash(id+[ancestry/timestamp])) unless I realized that they make edge certs (!) possible.

Hm, well monotone doesn't already have an ID on this? The lack of ancestry hashes makes loops possible, and leads to various hateful effects...

More ID namespaces will not make it more easy to understand monotones concepts but edge certs are the way other VC systems work. Perhaps designing them as edge IDs (hash(id+ancestry[+timestamp])) instead of hash(a big context text blob which even contains changelog) would be even more desirable.

I'd actually be relatively in favour of not troubling the user with manifest IDs at all. Could not pretty much all monotone operations which currently take a manifest ID operate equally well with a context ID (/edge ID)? Only one concept to explain to the user. Am I missing something?

Though there's no easy way to edit a changelog afterwards once the information is stored in the combined form [disadvantage of the combination].

At least for my way of working, this is an advantage. You can add *more* changelog afterwards pointing out errors in the original or expanding on its content, and have that in a second commit (or a cert). But the original is still there and everyone can refer to it. Allowing editing of the original changelog introduces a non-versioned element into the system, which for a versioning system, has to be a bad thing?

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com




reply via email to

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