[Monotone-devel] Re: Comments on monotone

[graydon hoare]

Johannes Winkelmann wrote:

> * Should I use one key per project or global one (a single key for all
>   projects)?

up to you. like with most key management issues; do you have 1 ssh key, 
or many? it depends how much you want to partition security. I tend to 
only use 1 key everywhere, because I am a bit lazy.

>   * If global, take a note in the docs that genkey is 
>     only needed at first

maybe a little digression about key management would be good in the docs?

>   * Where do I keep a global key? How do I access it 
>     from a remote PC (e.g. password protected area on 
>     web page); -> strategies?

there are a few strategies here. we've considered trying to teach 
monotone to talk to ssh-agent, and/or reuse ssh keys. likewise gpg and 
gpg-agent. we've also considered giving monotone its own agent. it's 
hard to decide; I'd probably welcome code which did any of these.

one thing I don't really want to do is wire into the gpg trust system 
automatically. trusting someone wrote you a particular email is a 
different thing than trusting their code is OK for your development project.

> * Explain branch naming (is net.venge.monotone meant 
>   for the developer working on venge.net or the project 
>   hosted at venge.net?)

it's just prefixed by a domain name to make it more likely to be unique. 
the names are hierarchical left-to-right to permit grouping in various 
operations; though so far the only grouping operation is serving a 
collection (eg. serving the collection net.venge.monotone also serves 
the branches net.venge.monotone.{i18n,win32,gui} as part of the same 
collection.)

whether this grouping is necessary depends largely on how many branches 
people make. each collection costs a full merkle tree in the database; 
grouping those saves a bit of cost if you have hundreds of branches. but 
maybe that's a premature optimization.

> * If I start working on a project (e.g. 
>   monotone/net.venge.monotone), should I start a new 
>   branch or commit to the existing one?

depends if you want monotone to try to merge your work or not. basically 
the idea with a branch is summed up in the term "merge obligation": if 
you mark your work as belonging to a branch, monotone will interpret 
that marking as an instruction to try to merge your work with everyone 
else in that branch.

if you want your work to remain not-merged for a while, you mark it as 
belonging to a different branch. branches can overlap, and you can mark 
a state as a member of a branch retroactively.

>   a) If I commit to the existing one, it would be nice 
>      if pull could "commit" to a different local branch, 
>      e.g. pull branchA and commit to branchB; this way, 
>      I can pull someone's branch without messing with my 
>      precious branch :-)

no, monotone doesn't (and won't) synthesize branches this way. what you 
pull is a set of certificates from other users saying that they want 
their work to be considered part of a branch (a logical, merged group). 
if you don't want to be part of that group, you need to mark your work 
as belonging to another branch.

note: this is not to say that your work will be clobbered by new work 
you pull. there can be multiple divergent heads on a branch. branches 
can have lots of forks inside them. your work is a fork from its base, 
and will remain a fork until you merge it. the branch is just an 
instruction to monotone that -- eventually -- you want a certain merging 
to take place amongst your fork and the others in your branch. probably 
we should make forking and branching clearer. the definitions for 
monotone are:

  - a fork == any time you create any divergence. usually
    any time you commit, at all.

  - a branch == a group of tree states, which monotone should try
    to merge the heads of.

in other words, a fork is a record of the ancestry relationship between 
tree states; a branch is a "social grouping" of such forks, telling 
monotone how you want it to behave when you ask for merges.

>   b) For a group of people working on a project hosted 
>      at example.net, should they
>
>      1. use a local branch (net.example.$DEVELOPER), 
>         merge to net.example, and push net.example,
>
>      2. work all on net.example

you would do #1 if you wanted to, say, have a designated person playing 
the role of integrator. you would do #2 if you were comfortable with the 
CVS style of having everyone do a little bit of integration on an 
ongoing basis. or you can do a mixture (eg. tell people to work in 
groups of 3-5 people doing ongoing integration on a shared branch per 
group, and appoint a few people to doing cross-branch integration).

it's similar to CVS in this sense, less like arch: you can share a 
branch amongst a group of developers, even without access to the same 
machine.

> * For a public development branch, is it possible to 
>   enforce merged heads (lua hook)? This would ensure a 
>   single access point for people not familiar with the 
>   developers and/or wouldn't want to care which head 
>   they should check out. Consider the following 
>   example: net.example.program, 
>   net.example.program.testing where the later is a 
>   testing branch for public testing (by non 
>   developers). Note that this "must be merged" lua thing 
>   is only for monotone running on the central 
>   development server, not the local copy. Of course, 
>   this could also be a policy of the development team, 
>   but enforcing it would be much more sane IMHO.

hm. possible. but I think a bit less useful and a bit more artificial 
than it sounds. maybe not. an easier thing to do, if you want to enforce 
this, is to make a policy (perhaps in lua) of doing a propagate from 
net.example.program to net.example.program.testing when you have a 
single head (or better yet, certificates indicating a successful build 
and testsuite result).

> 3 Functionality I was somewhat missing
>
> * getting (downloading) the latest version (any 
>   arbitrary version?) of something ("CVS snapshot"), not 
>   the whole repository (this is actually nothing I needed so far, but
>   thought this would help once I set up a public repository).

yeah. there's some planning in this direction (netsync can inhibit 
portions of its transfer, or make direct requests) but no code yet. 
there will be eventually, once we find time and work out UI for it.

> * How can I get someones changes into my DB, check 
>   them, and get rid of them (pull/review/drop cycle)?

similarly, all the stuff for truncating history (and marking as dormant, 
so you don't re-fetch it) is atm not written, but planned.

> * "pull" in a working directory could also guess the 
>   branch if omitted

yeah. pull actually operates on collections rather than branches, but 
the difference is artificial and possibly not worth maintaining. I'm not 
sure. in any case, we want "monotone pull" (with no other args) to 
eventually work in a working copy. it's a UI thing which does need a 
comfortable solution, no question.

thanks for your comments.

-graydon