There is no thorough explanation for how to have an svn-like setup

This may help: http://bazaar-vcs.org/BzrForSVNUsers?highlight=%28lieutenant%29

I think the intent of the submitter is actually to say that there should be a "user story" document describing from end to end the process and ideas around using bzr in this way.

The thing about "getting a list of branches project-wide" perhaps still needs actual tool work, unless you are using launchpad (which I don't think the submitter wants to do).

There is also

http://bazaar-vcs.org/Tutorials/CentralizedWorkflow

I would like to get more information about what moshez was looking for.

I think some of it is just like SVN, where if your project is disciplined to put their branches in a common layout, then you go to that location and look.

For example, getting my list of branches for bzr involves going to:
http://bzr.arbash-meinel.com/branches/bzr/

And possibly going into one of the sub directories:
http://bzr.arbash-meinel.com/branches/bzr/0.15-dev/

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.

Another possibility is to work with Moshez more directly, and just document the things that we run into. Since I personally don't really know what an SVN user is looking for (having migrated more from CVS => bzr than SVN).

[...]
> 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.

The Twisted project uses UQDS (see http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem ),
and we use an approximation at work. I would like to see how to implement such a system using bazaar -- including world-viewable user branches, versioned deletion of merges, and the ability to see a log of the mainline as a "one patch per branch merge". UQDS is more or less a natural way of doing work with SVN, and this is what many people are used to (sometimes in a less strict form of "some branches don't require review, some patches go immediately to trunk").

If you need help on deciding how to layout your repository read http://bazaar-vcs.org/SharedRepositoryLayouts
The use of repositories in general is described on http://bazaar-vcs.org/SharedRepositoryTutorial

True, and there is also http://bazaar-vcs.org/Tutorials/CentralizedWorkflow.

But we don't have a direct response for UQDS, and I think we should (it is a really good workflow), which is why I left this bug open.

John A Meinel on 2007-05-03 was the last person to write on this open bug #88064, I have little to say when people of such high repute speak, however this bug has been open for more than 2 years. Open and dormant.
IMHO, the documentation on migrating from SVN is quite adequate and clear. As I have "migrated" from svn to bzr, I feel that the documentation has now become quite adequate tor this migration procedure. In fact, following the suggestions, my own project, easmy (Engineering Analysis of Structures Made easY) has followed the route of mimicking svn repository layout and I did not find the documentation for it inadequate.

I would suggest that it's time to close the bug, unless John A Meinel insists otherwise.
OldAl.

OldAl, this bug isn't about migration.

(I should be more clear: we still get people asking for help about doing things in an svn like way on IRC - some users are either not finding our docs, or not finding them clear enough.