Re: bzr repository ready?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I think we should only consider setups that are close to what was done
>> with CVS.  After that, people can read the Bzr docs to figure out what's
>> best for them.
> FSVO "close to CVS."  Specifically, I *strongly recommend* that all
> workflows recommended to core developers start by creating a local
> repo (try that in CVS! :-).

I consider Bzr unusable without a shared repository (just like Arch was
unusable without a "revlib"), so I fully agree.

> 1.  Jason's suggestion of "bzr init-repo --no-trees -2a" sounds like a
>     good idea to me for performance reasons.  Is this going to be
>     entirely superseded by the "wget; tar x" workflow?

I think so, yes.

>     "emacs" trunk branch).  I think it's worth planning for that
>     possibility in structuring the Emacs Bazaar repository.

You mean the main repository should not be directly at .../srv/bzr/emacs
but at .../srv/bzr/<something>/emacs ?  I think I agree.

> 2.  I think that all core developer workflows we recommend *at this
>     point in time in the wiki page* should start with "bzr branch
>     trunk" (not usual in CVS but I think the rest of the workflow is
>     reasonably close to CVS).  I recommend exactly two variants:

I can think of only 3 useful starting points:
1- lightweight checkout: for people who only want to fetch the latest
   code but will never need/want the diff/log or contribute code.
2- bound branch (aka heavyweight checkout): for people who are happy
   with CVS and will never want to create a local branch.
3- a local mirror-branch + a local dev branch.

If you want something fancier than (3), read the Bzr docs.
I'm not actually convinced that (1) and (2) are really that important,
so maybe we could drop one of them (or maybe both of them even).
But the hard part is to integrate those 3 starting points with the
"wget+untar" approach.


        Stefan