[Top][All Lists]

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

Re: [Monotone-devel] Ideas and questions.

From: jfincher
Subject: Re: [Monotone-devel] Ideas and questions.
Date: Mon, 14 Feb 2005 00:16:57 -0500 (EST)

On Feb 13, 2005, at 3:21 AM, Nathaniel Smith wrote:

On Sat, Feb 12, 2005 at 07:44:09PM -0500, Jeremy Fincher wrote:
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 :))

I've considered "mtn"... you can always alias it, of course.

Sure, but there are some remarkably uncreative people in the world: I think monotone would do best to adopt an abbreviated name now, while it's young and while the scripts that people are writing can be standardized to a specific name. I meant to suggest "mtn" as well, but forgot.

Don't understand the number of people who will see "monotone," and rather than think, "Eh, I can alias it to 'mtn'," will instead think, "O MY GOSH WHT A HORRIBLE INTERFACE THESE PPL SUX!!!!!1!!!" And yes, it's easy to say that the "patronage" of such people can be ignored, but in reality, I think it's hard to justify losing some "customers" over something that trivially and easily "fixed."

It's worth noting (because I can almost hear it on your mind as I type this) that I'm concerned for Monotone's popularity *not* because I believe the Free Software world needs to have a One Version Control Program To Rule Them All, but simply because as a *user* of a Monotone, my life is made easier if Monotone is more popular -- the more people use Monotone and the more people at least know of Monotone, the fewer tutorials I (as the project lead for my project) have to give out.

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?

We don't have enough experience with people working on multiple
projects using Monotone yet, to really know what's best here.  My
sense is "one db per project" will be what people generally end up
doing, but *shrug* we don't really know.

That's my sense as well. Perhaps that should be suggested in the manual.

You could store a separate copy of your project's database in every
working directory, but it would kind of be a waste of space!

Of course! I would *never* advocate making every working directory a repo ;) (No, in reality, I've come to agree that every working directory should not be a repo; even if I hadn't, it would still be flagrantly wasteful to duplicate the same database if it weren't necessary)

You can't use a symlink to point to your database; sqlite will get
annoyed.  (Two instances of monotone using different names to refer to
the same database, won't be able to find each other's rollback logs.)

I assume that also applies to hard links.

Fortunately, monotone working copies know how to keep track of where
your database is, so you don't really have any reason to want to make
multiple copies of it.

Of course. I was only suggesting that it go into MT/ for easy organization, if it becomes the "best practice" of using MT that we have per-project databases.

I guess what I'm envisioning is an "easy" interface where a user of my software simply says, "mtn pull"; and it downloads the database (either by netsync, or by HTTP, then running integrity checks on the contents) and the database is downloaded into MT/db. Later, if that user wanted to get a new working directory, he could just say "mtn pull supybot supybot-my-branch" (where "supybot" is the directory he originally pulled into) and he's got a new working directory using the same database as the one he pulled from.

I think Darcs' single greatest (and perhaps only truly useful :)) innovation is the ease with which people can get "up to speed" using it, so if my example commands seem similar, it's not a mistake. I don't think there's any shame in looking at Darcs and saying, "Man, you guys have a nice command set."

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

Hmm, you misinterpret that text -- what it means is that the name
"branch" is privileged, it has special semantics, so we want to warn
people not to use it for any ad hoc certs they might want to create.

I just looked at it, but it's not obvious to me how to make it
clearer; any suggestion?

I suppose I was thinking there was a restriction on the certs on a given revision that they have unique names, but I guess I was wrong. If I can track down where that belief came from, I'll be sure to point it out.

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.

Eh.  Source code is for developers.

It certainly is, but you do need to keep in mind pre-developers, those people who desire to become developers, but who first need to acquaint themselves with the source code. When my decently large 80x51 terminal scrolls at a simple "ls monotone-0.16", that raises the bar for me to acquaint myself with the source code.

Developers have to type more if
they always have to say "src/" before they do anything.

With tab completion in my editor and on the command line, I've found this to be a complete non-issue in my project. I can type sr<tab> faster than greased lightning :)

"editing source files" is by far the most important use case of the
source tree... I'm kinda inclined to keep optimizing for that.

But that's the thing -- *especially* when I edit, I don't need to type the "src/", because when I open a file in emacs, it automatically looks for the file in the same directory as the file behind my current buffer. So I open one file in src/, and the next time I open a file, the src/ is already there.

Whether you agree with me or not, I hope we can both agree that the effect of typing "src/" before a source file is *minimal* compared to the actual effort involved in editing the source file itself. So this "optimization," even if it is one (in my case, I'd argue that it isn't) is an amazingly small one. On the other hand, making the source tree more organized by sequestering the source code in its own src/ directory *significantly* eases the task of a new developer acquainting himself with the project, and I believe that the saved effort in that case far outweighs any small typing savings that might be gained by not so organizing the source tree.

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.


This does assume that developers behind firewalls will still be able
to _push_ to a public netsync server, acting as clients; is that a
crazy assumption?

Sometimes it might be, but I'd say that's a corner case that isn't as important, at least not immediately. Generally, such developers should probably be clueful enough to figure out how to transfer their patches.

How to do synchronization with a dumb HTTP server:
Export your database to a bunch of nicely arranged flat files.  We'll
actually synchronize two directories of these flat files.  The
interesting part is how to make them "nicely arranged".

Let's define a "merkle directory" format.

What the heck is a "merkle"? I've seen that work a lot, and some in the source code, but I'm still not quite clear what it is.

Sorta baroque, but really not that complicated, and the hooks needed
to do it aren't very complex...

Is there a reason we can't just publish the database itself on the web, and just download that?

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?

There's no reason we can't define some parseable format that contains:
 -- text of a revision
 -- human-readable cert data for that revision
 -- little unobjectionable blobs of base64'ed signature data for those
    certs (maybe at the very end of the file)
 -- human readable unidiffs for each file changed in the revision,
    relative to each parent of the revision
and then have a way to import these (checking of course that when the
diffs are applied to the specified file versions they produce files
with the expected sha1, etc.).

Simple Matter of Programming, basically, and it would be rather handy.
Just no-one's done it.

It would be *rather* handy. In fact, it's the only reasonable way I can think of to make a trial implementation of my "picking and choosing patches at better-than-file granularity" -- without this, it seems I'd have to duplicate an entire working directory, apply the "mini-patches" the user selected, and then call monotone with that working directory.

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.

I'm not sure that netsync is really harder overall, given the vagaries
of dealing with HTTP servers and the mail infrastructure, but hey, if
people want it...

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?

All monotone databases everywhere, which is why we recommend embedding
a domain name into your branch names.

Oh, well I think that certainly needs to be fixed :)

I noted when reading the manual for the SCM that Linus Torvalds uses that when a project is initially imported, a "project key" is randomly generated. Any subsequent tree that is created using the "clone" command copies this project key. Perhaps Monotone could use a similar concept with branches; there could be a "branch" object which maintained such a randomly-generated key, and branch certs, rather than include a name, would include a reference to that branch object. That way, if I synced with a database that had a branch with the same name that was semantically different (i.e., was created by someone else for some other purpose) my database would refuse to accept it because its key differed from the one I already have in my database.

That way, the recommendation that branches have unique names could simply be for convenience, not for the integrity of databases.

Or I could be misunderstanding the reason for this restriction entirely, that's another possibility :)

Of course, if you never sync with anyone working on a different
project, then it won't matter if your branch names conflict.  But
that's an assumption that you probably don't want to make.  It's quite
handy to be able to share a netsync server among people, or perhaps to
pull multiple projects into a single database to merge between them
(e.g., if sqlite used monotone, monotone's own source tree could merge
in a branch of it to create the sqlite/ directory, and we'd get
history sensitive tracking of upstream changes that way).

There's also how things work conceptually.  In your mental model of
monotone, it's useful not to think of databases as distinct objects.
Rather, there is One True Database In The Sky, which we modify every
time we hit "commit" or "merge" or whatever.  Any given database has
some partial knowledge of the One True Database; netsync is how
databases share what they know with other databases, so that their
knowledge increases.

I think that's an excellent idea, but I also thinks that's another reason why namespace collisions need to be handled more gracefully -- I think that's exactly why the scm-which-will-not-be-named generates a project key for each initialized project, and duplicates it when that project source tree is cloned.

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.

Eh, umm, could do that with some UI, I guess.  Right now we let you
pick changes with file granularity.  I'm not sure how to do better
than that with a reasonable UI; I'd sorta rather not get into the
whole "designing an interactive text UI" thingie.  It shouldn't be
hard to write it as a 3rd-party kind of add-on, though.

The second I can generate a plain-text patch in an appropriate format and can import that patch into a Monotone DB, I'll write the interface for this. It's something that I and every significant Supybot developer have found *immensely* useful in the brief time we've been using Darcs.

"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."

What exactly does this signature mean? :)


reply via email to

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