[Monotone-devel] Re: Re: Deleting branches

[graydon hoare]

On Mon, 06 Sep 2004 10:32:54 +0200, Christof Petig <address@hidden> wrote:

> Since no data is lost (only hidden) I do not think this defeats the
> purpose of a version control system (or conflicts with netsync's design).

I wanted such things earlier on, but I have come to think they are
not compatible with the design. or rather, that they have larger
security implications than at first seems; perhaps they'd be harmless
on changelog and email certs, but it's mostly harmless for those to
appear in duplicate anyways. the real problem occurs with branch
certs, since they have a strong operational interpretation.

the problem is that certain activities in a monotone-managed workflow
involve pushing data out to non-monotone-managed environments, and are
taken based on the *current* understanding of branch membership. namely:

  - when I ought to update my working copy to a revision
  - when I ought to package and release a revision

these decisions are not generally "undone" by receiving modified
cert information (eg. a cert changing from "good" to "bad"). they
are imperative actions which do not record "what cert caused them
to happen", so they are not automatically un-done when the causal
cert changes. you can think of them like, say, the dreaded i/o
actions in a functional programming environment. even if monotone
knows they are no longer correct actions, it doesn't always have
the ability to revoke them from having happened.

rather, these sorts of actions can only be "undone" by clobbering
them with new revisions. so this is how I intend to approach the
matter of modifying existing information: if revision X is
mis-committed to a branch A rather than B, the "proper" way to fix
it is to certify X as a member of B and *also* to commit a revision
Y=invert(X) as a child of X and certify Y as a member of branch A.

iow, you cannot make X "stop being" in A, but you can make "un-X"
follow X in A, and this will have a much greater likelihood of
correctly clobbering "externalized" revisions when they are next
published. does that make sense?

-graydon