[Monotone-devel] Ideas and questions.

[Jeremy Fincher]

Let me first say that after re-reading the Monotone manual, I'm fairly 
convinced that Monotone may well be the future of distributed version 
control.  It seems to cover all the major bases I would expect such a 
system to cover, and is amazingly well-thought-out.  What follows are 
just a few of the questions and ideas I came up with while reading the 
manual.

1. "monotone" is too long a command name.  Perhaps a shorter command 
name can be offered, say, "MT" (lowercase "mt" is taken, unfortunately, 
but I'm willing to press shift :))

2. I noticed in the manual, each user in the test project named his or 
her database "abe.db" or "beth.db" and put it in his or her home 
directory -- does this mean that I use one global database for all my 
Monotone-managed projects?  If so, what is the advantage of this, 
compared to storing a database (or a link to it) in each working 
directory's MT/ directory?

3. It says in the manual, "the cert name branch is reserved for use by 
monotone."  Does this mean that any given revision may only belong to a 
single branch at a time?  If so, why is that?  If not, what am I 
missing?

4. This is just a pet peeve of mine, but what are the chances that 
Monotone's source code (.cc, .hh files) can be moved into a src/ 
subdirectory of the main distribution tarball?  As it currently stands, 
an "ls" in my monotone-0.16 directory doesn't even fit into my 80x51 
terminal, and that would be fixed if the .cc and .hh files were in 
their own sequestered directory.

5. I'm fairly convinced that Monotone is using the proper "model" for 
version control, but there are user-interface considerations that I 
think would aid in doing the kind of distributed development Monotone 
is aiming for.

  a. I think there should be an easy way for someone to publish a 
pull-only repository via
      "commodity" (e.g. HTTP) protoocols.  Many people may be 
firewalled or otherwise
      prevented from publishing  their repository via a monotone server 
process, but anyone
      worth his or her free software developing salt should have some 
webspace somewhere
      to which he can publish a respository.

  b. I think there should be an easy way for a user who publishes a 
repository in such a
      manner to accept patches via another "commodity" protocol (e.g. 
SMTP) and perhaps
      apply them automatically if they're appropriately signed.  Come 
to think of it, is it
      easy/possible for Monotone to "export" a new revision (changeset) 
along with all its
      attached certificates, etc., in such a way that the exported file 
may be imported by
      someone else who isn't able to connect to a monotone server for 
some reason?

  Mostly what I'm concerned with here is that Monotone's goal seems to 
be to make distributed
  development easier, but requiring that change propogation occur 
through netsync (and thus,
  through channels which may be hard to use through various firewalls 
and other annoying
  devices) raises the bar significantly over, say, Darcs, which just 
allows the user to copy his
  repo to his webspace and publish a URL.

6. The manual said that branch names had to be unique globally -- does 
this apply to all Monotone databases everywhere, or just the ones that 
are working on my project?

7. One of the things I really liked about Darcs was the ability for me 
to specify exactly which changes in which files I wanted to record as 
part of my patch.  Oftentimes I'll have several semantically unrelated 
changes active and unrecorded in my working directory since I follow a 
sort of stack workflow, rather than a queue.  It was especially nice to 
be able to continue working in that way and trust that when I got 
around to recording the changes I'd made, I could pick and choose 
exactly which ones to put into which patches.

Those are just a few questions and comments I had.  I'll probably have 
more, but I'm curious about these ones right now :)

Jeremy