monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] understanding mtn serve


From: Sebastian Rose
Subject: [Monotone-devel] understanding mtn serve
Date: Sat, 20 Sep 2008 18:25:21 +0200
User-agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)

Hi,


I'm trying to set up a monotone server for the first time here and
have some questions about it. Here is a little test db I created. I
added two separate branches with no common ancestor, since it seems
this is the only way to serve two projects (p1 and p2 in this case).


$ mtm -d test.mtn db init
$ mkdir p1 p2

# starting p1 as a branch without ancestors:
$ cd p1
$ mtn -d ../test.mtn setup -b p1 .
$ echo 'File in p1' > p1.txt
$ mtn commit -m'Starting project p1'


# starting p2 as a branch without ancestors:
$ cd p2
$ mtn -d ../test.mtn setup -b p2 .
$ echo 'File in p2' > p2.txt
$ mtn commit -m'Starting project p2'

# Now add some confusion:
$ echo 'More text here' >> p2.txt
$ mtn commit -m'Two heads in p1 we never can merge' -b p1

Here mtn says that p1 has two heads and suggests 'mtn merge' which
will fail. If we just look at the branch names on the graph, this is
how it looks like:

Timeline p1:  p1
Timeline p2:  p2 --- p1


OK, I can't see how to avoid this confusion using write-permissions on
the server side. And still, it's inconvenient. And the suggestion to
apply 'mtn merge' seems wrong if the two head revisions on branch p1
have no common ancestor --- which I'm not shure of (actually this unsure
feeling is the reason for writing this email). Maybe those braches could
be merged by solving the conflicts?





* Questions


1) First of all it seems, that 'mtn serve' serves exactly one database.
At least I can't find anything about serving multiple databases in
the docs. Is this true?


2) If 1) is true: is it the recommended tactic to set up more than one
project as different branches with no common ancestors (which inhibits
propagation from branch p1 to branch p2)?


3) Is there a way to restrict branch names in a way, that creating a new
branch for project p1 always has to be in the form 'p1.BRANCH' ? Or have
I to ensure those naming conventions entirely by setting up system of
read and write permissions?

I feel it would be convenient for all the clients to know if a branch
they just created can be pushed to the server. Something like:

$ mtn commit -m'creating a branch with a forbidden name' -b BRANCH
...here is what monotone says now plus:
Default server does not permit a branch with name BRANCH






Thank's for monotone,

 - Sebastian







reply via email to

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