[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] monotone newcomer - several questions
From: |
Dirk Hillbrecht |
Subject: |
[Monotone-devel] monotone newcomer - several questions |
Date: |
Fri, 20 May 2005 20:55:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; de-AT; rv:1.7.7) Gecko/20050414 |
Hello everyone,
I'm the chief developer of a smaller IT company. Currently, I'm
investigating where to move to from CVS when it comes to versioning
control. I finally stopped when looking at monotone as it seems to
fulfill my most important wishes: Distributed operation, simple usage,
sane design. So I started deeper investigation by doing some "real-life"
tests with our projects. As I expected, a bunch of observations raised a
number of questions I would like to ask here.
Perhaps as preface: I'm coming from CVS and CVS only. I am managing the
projects in question now for eight years with CVS. My current approach
to monotone is more or less "CVS with one more layer", so the main
repository server is an important thing for me. Furthermore, our
projects are handled through multiple CVS modules in the repository - I
want to take the chance to even extend this arrangement during
transition. And my tests involved, of course, the conversion of a
medium-size CVS module. I took our properties-module which contains all
the i18n'd messages. It contains about three years of development
history cumulating in 1125 files, about 4300 checkins/revisions and a
monotone db file of 7.4 MB. So, here are my questions:
- 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?
- 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?
- 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?
- Any chance or any plans to start a monotone serve process via inetd? I
mean, it would be the perfect environment for that one...
- 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?
- Is the communication during "sync" in some way encrypted?
- 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?
- 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?
- 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)?
- 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?
- 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?
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...
Best regards,
Dirk
--
--- Dirk Hillbrecht, cantamen GmbH --- address@hidden
--- Hausmannstraße 9-10, 30159 Hannover, http://www.cantamen.de
--- Tel.: +49/511/5902626-0, Fax: +49/511/5902626-4
- [Monotone-devel] monotone newcomer - several questions,
Dirk Hillbrecht <=