Comment 4 for bug 88064

[...]
> But it really comes down to project policy. And while we can give a
> "recommended" policy (do it like you did it in SVN and then things will
> look like they did in SVN), it is open to personal desires.

We should have a recommended policy. e.g. when SVN was new, people didn't know
how to arrange their repositories, so having reasonably official documentation
telling them to have "project/{trunk,branches,tags}" directories was very helpful.

Before users understand shared repositories, no-trees repositories, checkouts
vs. branches, etc, it's obviously difficult for them to make sensible choices
about them. So we should try to suggest a default policy for them to follow
where they don't need to worry about those choices right now, and just get
started.

As a rough idea for a centralised development policy, how about:

  * all users have accounts on a shared system
  * all users are members of a common group, so they have write access to a
    common directory owned by that group.
  * that directory has "bzr init-repo project1" done in it to get the repo
    started. (should the group sticky bit be set on that dir?)
  * that repo has "bzr init trunk" done in it to get the first branch started.

Then we can take users through making checkouts, branches, etc, as we already do
in various existing docs. I think this is likely to fit reasonably well with a
project's existing centralised development practices, and it gives a sane
starting point.

It would probably be good to have a similar "recipe" for getting started with
fully-distributed development of an open source project where contributors
publish to public web space rather than a common filesystem.

-Andrew.