[Top][All Lists]

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

[Monotone-devel] Ideas and questions.

From: Jeremy Fincher
Subject: [Monotone-devel] Ideas and questions.
Date: Sat, 12 Feb 2005 19:44:09 -0500

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 :)


reply via email to

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