[Monotone-devel] Re: Deleting branches

[Peter Simons]

Thanks for the replies, guys. I'll answer your postings
all-in-one style here, if I may. First of all, my comment

 > Not that I expect anyone to care what I want. :-)

was _not_ meant as an accusation. I know you care about your
users' opinion, I didn't want to imply that were not the
case. What I meant is that all my "requests" are made in the
spirit of: If I really, really want to have it, I can submit
code. It's free software, after all. So while I may request
things from time to time, I am aware that I will not
necessarily get it. I don't "expect" anyone to work for me
without getting paid. That was all I wanted to say with that
sentence.


Nathaniel Smith wrote:

 > There's a basic assumption on monotone that all data is
 > universally valid and immutable -- if something has ever
 > existed, it will always exist.

I don't think that's a good assumption to make, especially
not in a distributed version control system. Doing so would
greatly limit Monotone's usability, because I may want to
keep data under version control, which must be deleted (by
law) at some point. Customer's data, for instance. This type
of data will, obviously, not appear in a public netsync
repository, definitely not in a repository I don't control.

I am aware of the problem that deleted branches must be
deleted in all repositories I synchronize with, but that's
not a problem in my case. Most of the data I keep under
version control never makes it into any netsync repository
at all. I need those functions strictly for keeping my own,
private database "clean".

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.

I could also work with multiple databases, or create them
temporarily for experiments, but doing so is, as I said,
somewhat cumbersome. More often than not, I only realize I
need to experiment to get it right after I already _have_
screwed up the branch architecture.


 > Of course, maybe you're just talking about making little
 > local screwups that you want to back out before doing
 > netsync, in which case, yeah, such commands would be
 > handy [...]

Yes, that is exactly what I meant. :-) Most of my data lives
in my own private "simons.db" and never makes it into a
netsync server.


 > I'm actually kind of unclear on what you want to use this
 > for.

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.

The other case, where I want to delete (or rename) whole
branches, is the one I mentioned above. I often use
temporary branches that I'd to get rid of afterwards, I
often realize a branch should have belonged into some other
hierarchy, etc.

I'd simply like to be able to maintain my database without
having to learn its internals on the SQL level.


Graydon Hoare wrote:

 > I wish I had time to implement a lot more such things,
 > but I can only really reprioritize things so much before
 > I conclude that "the list is currently too long".

I understand your problem very well. I only wanted to point
out what I think is a worth-wile task, and why I think it
is; I realize it doesn't mean that somebody will actually do
what I want. If in doubt, I'll do it myself. The reason why
I don't is the same you mentioned: I have too many other
things to do. :-(


Derek Scherger wrote:

 > Removing the concept of a collection (as graydon has
 > mused previously) and using branch names (and globs)
 > directly in netsync might help in terms of serving and
 > syncing specific branches.

Yes, replacing "collections" by synchronizing (pattern
matched) branches is a good idea, IMHO. This would make
copying branches hence and forth between arbitrary databases
much easier.


 > I think the idea of a lua hook like ignore_branch(name)
 > might be a good idea.

I don't think that hook would help me any. Sorry. :-) I
really want to remove data from the database, I don't want
to hide it.

I think "hiding" might be something that would better be
accomplished through the _trust_ hooks. I'd hide a branch by
not trusting it's certificates. Of course, implementing that
is -- or so I believe -- very tricky at the moment, because
the trust hook doesn't get the branch name as an argument.
Hint, hint.

Peter