Re: bzr repository ready?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > 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! :-).  Questions for those who have actually
used bzr on the emacs repo (for the moment, I'm not interested in
GPLv3 code but we're working on that :-):

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?

    N.B. Many projects that convert to dVCS start to proliferate
    "sandbox" branches, cf. http://code.launchpad.net/mailman/ or
    http://git.kernel.org/.  I *think* that if the same base URL is
    used to host such sandbox branches, it won't cause any problems
    for the "wget; tar x" workflow" (you just do tar c only on the
    "emacs" trunk branch).  I think it's worth planning for that
    possibility in structuring the Emacs Bazaar repository.

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:

    a.  A generic "dev" branch for small one-off fixes.  I recommend
        the branch name "quickfixes" or something like that instead,
        to more precisely indicate the purpose of the branch.

        I would do this kind of work directly on a trunk checkout in
        CVS.

    b.  Feature branches for any work that might involve concurrent
        commits in other branches you're working on locally, or might
        span several updates from upstream.

        I would do long-running tasks with many commits on a branch in
        CVS, while relatively short tasks (which nevertheless span
        multiple updates from upstream for whatever reason) would be
        done in the trunk checkout.  The latter half I consider
        suboptimal though, and I hope people transitioning from CVS
        would find it as natural as I do to crank the threshold for
        feature branches way down.

3.  How do people organize their branches (bound or not) and
    (lightweight) checkouts?  Eg, for my desultory work on GNU
    Mailman, I have

    Mailman -+- 3.0                # all toplevel branches are mirrors
             |                     # and are configured treeless
             +- 2.2                # defunct
             |
             +- 2.1
             |
             +- work -+- 3.0       # all local branches and checkouts
                      |            # will be placed under work/
                      |            # work is an ordinary directory
                      |            # 3.0 is also registered on Launchpad[1]
                      +- lilfix    # these are both branches; "lilfix"
                                   # is a historical relic, I think
                                   # "quickfixes" is a better generic
                                   # recommendation


Footnotes: 
[1]  I don't know if "registering a branch" has a corresponding
feature on Savannah, but I thought I should mention this fact.