Re: [Monotone-devel] Ideas and questions.

[Jeremy Fincher]

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 http://source.supybot.com/supybot"; 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
> > missing?
>
> 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 :)

> Since
> "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? :)

Jeremy

P.S. Sorry if you got this twice (or worse, more times), Nathaniel, 
I've had some issues sending it from the proper address.