[Top][All Lists]

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

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

From: Derek Scherger
Subject: Re: [Monotone-devel] Removing things from the database
Date: Tue, 15 Feb 2005 09:28:04 -0700 (MST)

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...


reply via email to

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