monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: next release


From: graydon hoare
Subject: [Monotone-devel] Re: next release
Date: Mon, 27 Dec 2004 15:33:41 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Richard Levitte - VMS Whacker wrote:
In message <address@hidden> on Mon, 27 Dec 2004 14:15:37 -0500, graydon hoare 
<address@hidden> said:

graydon>    - make a "rechangesetify" command (suggestions for a nicer
graydon>      name welcome) which rebuilds the rev graph from the
graydon>      underlying manifests, with predictable rename lossage

Uhmmmm...  I probably missed something.  Why do we need to
changesetify *again*?

yes. there was a bug in the changeset merging code which produced (and saved, published, shared all around) some completely bogus changesets. like, they make no sense. you can read them, they are structurally sound -- they can parse and print -- but logically nuts. they describe combinations of additions and patches which don't have any sensible interpretation, and shouldn't occur there anyways. they don't describe the differences between the manifests on either side.

the presence of these "bad" revisions is something we can detect, and fault on. unfortunately every bad revision has a hash code, and this code is used as the ancestor for revisions which follow it. so everything "after" a bad revision is essentially tainted with some badness.

the badness is only so bad: you won't encounter it unless you want to do a merge which traverses one of the bad edges, during a propagate or common-ancestor search. the rest of the time it's just "crazy history". but we discussed this a bit on IRC and largely came to the conclusion that it's better to remove the badness now by rebuilding the graph than it is to let it fester there for years.

-graydon




reply via email to

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