Re: [Monotone-devel] monotone newcomer - several questions

[Nathaniel Smith]

On Fri, May 20, 2005 at 08:55:24PM +0200, Dirk Hillbrecht wrote:
> - My idea is to put each of our projects into its own monotone database. 
> As we have 8 to 10 projects, this would mean 8-10 distinct .db files. Is 
> this the way to do things?

It's generally a good idea to put each project you work on into a
separate database; this just makes things a little more flexible.

> - When I have my different projects, of course, all of them should be 
> reachable at the "main" server where a "monotone serve" process runs 
> continuously. However, there seems to be no way to let one server serve 
> multiple databases. My idea was to start one server per project (= 
> database) and each one to listen on a different port. Not precisely what 
> I would say to be"resource-friendly", but, hey, it's version 0.19... 
> Would this work? Any better ideas?

It would work.

You could also just put all the projects into a single database on the
server; this wouldn't stop you from keeping separate databases on the
client.  A database in monotone is just a bag of information, you can
take out or put in whatever you like to each bag.

> - A propos "server process". That one is rather err... simple, isn't it? 
> There seems to be no really nice way to start and stop server processes 
> from startup scripts. My idea is to start all my nice little servers as 
> a certain user from a script into background and when it comes to 
> stopping them, I would simply issue something like "killall -HUP 
> monotone" as that user. Feasible? Additionally, I would issue that 
> stop/start trigger each night, as I suspect monotone not being 
> guaranteed to be memory-leak-free. Correct?

I tend to recommend using "runit" for running the server; with runit,
things go from "somewhat worse than other servers" to
"somewhat _better_ than other servers" ;-).  There are some out of
date instructions on doing this at:
  http://frances.vorpus.org/~monotone/netsync-setup.html
(Not all of those steps are still necessary.  Random thought for those
reading this: a patch to include this sort of information directly in
the manual would be welcome.)

I don't know of any memory leaks, and monotone is written in a style
that makes it very difficult to introduce memory leaks; but I haven't
actually had a chance to run valgrind recently, so who knows.
Certainly if you do find it leaking memory, we'd like to know :-).  If
restarting it nightly makes you feel better, feel free.  (runit also
makes it very easy to restart a process.)

> - Any chance or any plans to start a monotone serve process via inetd? I 
> mean, it would be the perfect environment for that one...

It's a little tricky (because it would have to be started from inetd,
but then take over the listening port while running -- if two people
connect at the same time, they need to both end up talking to the same
process, not talking to two different processes).  But, maybe
sometime.

> - After having imported my before-mentioned archive into my own monotone 
> database, I sync'd with my "main server"-to-be, which had a totally 
> empty database at that moment. That needed very long, especially after 
> all data seemd to be transferred (byte counters did not increase any 
> more). Further syncs (after small changes in my local repository) ran 
> much faster. Intentional behaviour? What would have happened if I had 
> interrupted the "client" monotone while the server process was still 
> busy doing ... something. Would the sync have been lost? Would the 
> database have been corrupted?

If you had interrupted, the sync would probably have only partially
finished, and the next sync would "pick up" where the first one left
off.  It shouldn't be possible to actually corrupt a database under
any circumstances (modulo things like 'dd if=/dev/zero of=my.db', of
course).

It's slow because it's doing a lot of integrity checking on each
revision that comes in, to make sure that everything is consistent and
meaningful.  This is generally only a problem when pushing/pulling
into an empty database, and we're continuing to work on optimizing
this checking.

> - Is the communication during "sync" in some way encrypted?

No.  You can forward it over ssh, of course, if you like.

> - To allow someone to sync, I have to enable the user id in my 
> .monotonerc. Having several server processes serving different 
> databases, all servers share that settings. Any possibility to constrain 
> access for certain users to certain databases? Any plans to put these 
> settings into the databases themselves instead of that configuration file?

Instead of putting permissions into your monotonerc, use the --rcfile
switch, and give a different file to each server.  (Alternatively, the
various permission hooks all take a "collection" argument, which you
can use to choose who is permitted for each branch.)

> - If I sync my local repository with that "main server" and nothing has 
> changed since the last sync, the server logs an error:
> 
> ---
> monotone: accepted new client connection from a.b.c.d:37579
> monotone: rebuilding merkle trees for collection de.cantamen.i18n-ebus
> monotone: including branch de.cantamen.i18n-ebus
> monotone: including branch de.cantamen.i18n-ebus.xxx
> monotone: [certs: 2376] [keys: 1]
> monotone: fd 5 (peer a.b.c.d:37579) read failed, disconnecting
> ---
> 
> Is that intentional?

No, but it's basically just cosmetic.  Dunno how hard it would be to
fix; the problem is basically just that there's some small bug in the
connection shutdown logic.  It turns out that cleanly shutting down a
pipelined, asynchronous, symmetric protocol is tricky :-); it doesn't
mean that the connection didn't close cleanly, just that the server
wasn't quite able to figure out that it did...

> - For the first test, I started my "main server" on the default port. 
> For further tests, I changed it to another port (56001 or so...). 
> However, my local repositorie's monotone still tried to connect to the 
> default port if not explicitly told otherwise. I haven't found the 
> server default setting it recorded when connecting for the first time. 
> Did I overlook something or does it not store the port I connected to 
> (and changes it when I connect to another one on the same server for the 
> next time)?

It stores the hostname+port you connected to first.  To change it,
just run "monotone unset database default-server" and now monotone
will pick up the _next_ server you connect to as the default.

> - I played a little bit with the "log" function. Apart from it not being 
> path-aware I wondered whether there is a way to get a condensed overview 
> of the change history for one file. I mean, the history written by 
> "monotone log" is able to restict itself to one file, but is it possible 
> to get the output printed in a nicer way?

Not at the moment, no.

> - Dumping and restoring the database gives me exactly the former 
> content, doesn't it? Is it sensible to do regular dumps and keep them 
> for a while - just in case the database crashes and I have to go back to 
> a former (clean) state?

It shouldn't be necessary, but sure, it's another layer of protection
against bugs and hardware failure and what-have-you.  Monotone has no
objection to people taking precautions :-).

> Ok, huge bunch of questions. Perhaps you can give me some answers. 
> monotone is really nice and I am quite sure that I will bring it into 
> production usage rather sooner than later. If you can answer some of my 
> questions, this process could become even a smooth one. I suspect, 
> however, that I and my colleagues will have to change quite some habits 
> we are now used to, anyway...

Good luck!  If you have any more questions or feedback, please let us
know...

-- Nathaniel

-- 
  /* Tell the world that we're going to be the grim
   * reaper of innocent orphaned children.
   */
-- Linux kernel 2.4.5, main.c