Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <address@hidden> writes:

> Jason Earl writes:
>  > "Stephen J. Turnbull" <address@hidden> writes:
>  > 
>  > > But Bazaar branches *cannot* at present be colocated; they
>  > > *cannot* share a working tree.  That means that if you do a "bzr
>  > > branch" for a one-line change, you have to do a "make bootstrap"
>  > > to test.  EEEEEEeeeeeewwwwww.
>  > 
>  > That's not entirely true.  I keep a "workspace" checkout in my
>  > repository and then "bzr switch" between the branches that I am
>  > working on.
>
> Sure, what I wrote isn't 100% accurate.  But it's close enough, and
> reasonably intelligible to novices (at least I tried to make it so).
>
> So please, as Eli implicitly requested, let's talk one workflow at a
> time.  I'm fine if you want to change to a different workflow which is
> admittedly better, but what you just wrote is not an explanation of a
> different workflow, or even an admission that you *are* talking about
> a different workflow.  It's merely a laundry list of new vocabulary
> for novices to learn, with no definitions.  And Eli *did* ask about
> the workflow I wrote about.  In more detail:
>
> In git the workflow in question is
>

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "git checkout -b issue-oriented-task" # create and checkout new
>     branch.
> 3.  Hack away.
> 4.  "git commit -a -m 'Here is a problem and how I solved it.'"
> 5.  "make"
> 6.  Run tests.
> 7.  If problems, goto 4.
> 8.  "git checkout master; git merge issue-oriented-task; git push"
>
> These git operations are very fast and transparent; this is a winning
> workflow.  In bzr, the same workflow is implemented

On the one hand you chide me for adding a slight change to the bzr
workflow that you were criticizing while, on the other hand, you bring
up an entirely different set of tools.

If the criticism of bzr is that it doesn't have colocated branches
requiring several instances of "make bootstrap" then here is how you
solve it.

If what you want to do is talk about how great git is, then I suppose
that is helpful as well, but it certainly isn't going to help Emacs
developers that are switching to bzr.

The revised example assumes that you have a mirror branch named "trunk"
and a light checkout named "workspace" created in the bzr repository
like this:

bzr co --lightweight trunk workspace

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "bzr branch trunk issue-oriented-task"
> 3.  "cd issue-oriented-task"

3 (revised). cd workspace ; bzr switch ../issue-oriented-task

> 4.  Hack away.
> 5.  "bzr commit -m 'Here is a problem and how I solved it.'"
> 6.  Prepare to test: "make bootstrap"

6 (revised). "make"

> 7.  Run tests.
> 8.  If problems, goto 4.
> 9.  "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push"

With that one minor change the bzr workflow works just like the git
one.  Of course, it assumes that you have a checkout in your repository
called "workspace" where you do your work, but creating such a checkout
is a single command.

You can even leave off the --lightweight flag and it will work precisely
the same (at least from an end user's point of view).

> This workflow sucks because steps 2 and 6 are slow, but people more
> familiar with git than bzr are likely to remember it, adopt it
> themselves (and be frustrated and switch back to git), and recommend
> it to novices (who will also experience frustration).

If the repository is created with --no-trees, or if the step 2. is
replaced with "bzr branch --no-tree trunk issue-oriented-task" then step
2 is basically instantaneous.  On my underpowered Dell netbook running
Ubuntu GNU/Linux this is how long it takes to create a branch in bzr if
a workspace is not created:

time bzr branch --no-tree trunk/ foo
Branched 98737 revision(s).

real    0m0.771s
user    0m0.680s
sys     0m0.088s

I am sure git does it in half the time, but bzr is fast enough in this
case that I doubt anyone would care.

Since you are reusing the workspace (like git) now step 6 is precisely
the same as the git workflow.

> Now you're suggesting an alternative which is just about as efficient
> as the git workflow.  *But* there's an important difference.  Both
> workflows described above depend only on the existence of a mirror
> branch; otherwise they are standalone, they work just as well for a
> single contribution as for a regular contributor.  The workflow you
> are suggesting, though, has some components that look like the above,
> and others that involve preexisting context (several branches, for
> example) and new commands which are actually old commands with new
> names (bzr switch, at least).  Somebody needs to explain all that (and
> it's not going to be me, unless Tim O is about to offer me a book
> contract ;-).

For one off contributions the bzr workflow probably looks like this.

1. bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ emacs
2. cd emacs
3. hack
4. bzr commit -m "Hooray I fixed it"
5. Test
6. If problems 3
7. bzr send -o awesome-fix.patch

For CVS refugees that have commit rights and aren't interested in
leveraging bzr as a DVCS they can basically keep precisely the same
workflow that they currently use.

1. bzr co [the magical ssh url that I don't happen to know] emacs
2. cd emacs
3. hack
4. bzr up (no -dP needed)
5. bzr commit

The difference is that bzr will probably be faster for basically every
operation than CVS because it has a local cache.  Emacs' vc-mode stuff
will even do the right thing.  For this group bzr is almost certainly a
more straightforward change than git.  For example, there is no need to
worry about the push, pull, or merge commands.  Nor is there any
requirement to learn about how git juggles branches.  Perhaps best of
all vc-mode will work just like it always has.

Clearly, these are extreme cases, but they are cases that appear to
apply directly to Emacs development.  For those whose needs lie
somewhere in between it is probably a good idea to create a repository
that includes a light checkout that can be switched to various branches
so that you don't have to "make bootstrap" more than necessary.  This
requires a few extra steps (two extra steps, that only need to be done
once, to be precise), but unlike git, bzr doesn't force you to worry
about branches unless you actually want to start dealing with them.

If, like Eli, you aren't convinced that a DVCS is for you, then bzr
won't force you to learn to use one.  On the other hand if you really
like git's colocated branches bzr can be easily set up to approximate
them.

Jason