Re: [Monotone-devel] understanding mtn serve

[Thomas Keller]

Sebastian Rose schrieb:
> 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? 

Sorry, but I don't quite get what you want to achieve. Do you want to
_have_ or _avoid_ two projects that cannot merge or do you want to catch
the case that two people independently start checking in the code of the
same project and you're later forced to "somehow" merge them?

Either way, the answer is not write-permissions. This is an
all-or-nothing deal. People listed in there get write access to all
branches of the repository. And until *cough* policy branches *cough*
are implemented this behaviour won't get "fixed" (it would still be
possible for everybody to push changes for all branches, but afair
policy branches then let you setup a policy to ignore certain changes
making them "invisible" for other project members).

> * 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?

This is correct. Plain mtn serve only serves a single database. But
there is usher in nvm.contrib.usher (see the readme [0])

> 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)?

If you have two or more projects which should get distinct write access
the currently only route to go is to put each of them in a separate
database and serve them separately.

> 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?

No, you can't enforce anything with read and write permissions here. If
somebody pushes a wrongly named branch it might get "unpullable" (i.e.
invisible) for others if the read-permissions are very restrictive. If a
descendant of such a branch gets a cert of a branch which can be pulled
though, the history of this descendant will go into your database as
well. (One might correct me here, but I believe the branch certs are not
pulled in such a case, but I'm not sure.)

Still, the changes which are initially pushed to the wrong branch will
go into the database and there is nothing you can do about this.

> 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

Due to the distributed nature of distributed version control (the name
implies it) people would have to ensure that such a policy ("do not
accept revs with a branch not matching the branch scheme xy.*") is setup
on all nodes which can act as server. And again, this is part of policy
branches. You won't be able to hinder some attacker to push wrong
branches or certs to your database if he already got write access, but
through the distributed policy you can choose to ignore them and
eventually clean them out from your local database to save space.

If you have more questions about policy branches, ask around. There are
people around here which are more into the topic than me. I may only
seeing the tip of the iceberg here ;)

Thomas.

[0]
http://viewmtn.angrygoats.net/all/revision/file/c1c1fe91652a801ef20d396c7c03998ffc34b2d9/README

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature