Re: [Monotone-devel] Removing things from the database

[Derek Scherger]

On Tue, 15 Feb 2005, Julio M. Merino Vidal wrote:

> On Mon, 2005-02-14 at 15:18 -0800, Nathaniel Smith wrote:
> > On Sun, Feb 13, 2005 at 09:16:02AM -0600, Matthew A. Nicholson wrote:
> > > Currently AFAIK there is no good way to remove information from your
> > > database. For example say I just did a pull from the monotone repo here,
> > > but now I don't want that stuff in my local db any more.  I don't know of a
> > > way to delete that info from the database (not like deleting a branch or
> > > anything, just making it as it was before I synced up).

The trick with deleting things I think, is deciding how deep to go. If you 
want to delete a revision, it refers to a new manifest and this manifest 
refers to a bunch of files. Should all this stuff be deleted too? It's 
possible that deleting the manifest is ok but it's also possible that 
some other revision in your database also refers this manifest. It's also 
possible that some other manifest in the database refers to this manifest 
in terms of an xdelta operation against it to be created. Almost 
certainly most of the files in the manifest will be referred to by other 
manifests so deleting them is a no-no. There may be a few files that can 
be deleted, but they may also be used in xdelta operations to construct 
other files. To deleting something "properly" the entire database of 
dependencies needs to be analyzed so that something important doesn't get 
deleted.

All that being said, I'd like to be able to delete things too! I'm just 
not sure how to do it.

Deleting a branch for example, if this is done by just removing the branch 
cert you're, at best, leaving a certain amount of cruft in your db and 
quite possibly this cruft might escape to other db's. I'm not sure if a 
revision with no branch certs is really a valid revision either.

> It'd also be nice to be able to tweak existing certs in the local
> database, but that'd only be possible to do with certs that have not
> been synced against any server (see below).  I.e., you'd have to keep
> track of which certs are still modifiable and, when syncing (or pushing)
> mark them as untouchable.
>
> (This is why I sync often with my server, once I'm happy with the
> changes, so that I can rebuild my local database at will if I'm not
> happy with a given recent change.)
>
> However, having the ability to mark concrete certs as "broken" in the
> database could probably mitigate this problem (at least, from my POV).
> Consider that you do a commit and, for some reason, you write an
> incorrect changelog (either with typos, with missing information...
> whatever); this happens more often than one could think.

We were briefly talking about adding dates (statement-date and 
signature-date) to certs and I'm wondering if this might help here. 
Suppose we constrain some certs so that a given name/signature pair must 
be unique on some revision and if a duplicate arrives in your database 
during a netsync we keep the most recent cert. This would allow the signer 
of a cert to replace that cert by signing a new cert with a different 
value. I'm not sure about this though, it feels a lot like I can go and 
retroactively change history which is almost what a vcs is trying to 
prevent.

Renaming a branch seems to be a popular item on the wish list and I'd
like to be able to do that too.

Thinking out loud...

Cheers,
Derek