[Monotone-devel] Re: Deleting branches

[Bruce Stephens]

Peter Simons <address@hidden> writes:

[...]

> Monotone often requires multi-branch constructs to get the job done
> right, and often these constructs have to be experimented with,
> before I can figure out what the right way of doing things is. Thus,
> I start out with branches like "temp.foobar", just to play around
> with the data. I _could_ keep all those branches in my database
> forever, but I simply don't want to, because I _know_ I won't need
> them anymore.

That case seems reasonably clean: if I can point monotone at a set of
manifests that can be removed without removing any of the other
manifest's ancestors, then it seems reasonable that it could delete
them for me.  Together with any files that are subsequently not
referenced, and certs that reference files or manifests that have been
removed.

That would also allow one to remove ordinary commits in the case of
errors, so long as they're at the head, which is likely to be an
intuitive feature.

I've no idea what the user interface might be.  Perhaps you'd mark all
the manifests with a special cert type?  One that could also easily be
removed, I guess.

[...]

> I need to delete data from the database, for instance, when I have
> accidently committed a file which was _not_ supposed to go into a
> netsync repository. I keep the "/etc" hierarchy of many different
> machines in Monotone, for example, but only those files, which are
> really equal on all machines. So when I accidently add and commit
> "/etc/passwd", this is a problem for two reasons: (1) The file is
> not the same on all machines; and (2) I have now added the encrypted
> user passwords into the database, so anyone with read access to the
> Monotone database has read access to /etc/passwd! Thus, I need to
> delete this accident _before_ I can netsync again, or I will
> distribute my user passwords through the Internet.

I think that's much nastier.  That sort of implies restrospectively
altering manifests, and if you alter a manifest then its SHA1 hash
changes, and everything breaks!  

The cleanest way I can think of for doing that is to have a new cert
type binding a manifest to a censored version.  Then the censored
version would omit the files you didn't want kept, and those could be
deleted.  All relevant operations would need to be modified to look
for and use these new certs, of course, but in principle I think it
would be workable.

Someone with access to the repository would be able to tell that
manifests had been changed, which files had been removed, and their
SHA1 digests.  But that's probably OK.

[...]