Bzr: thrilling

[Edward K. Ream]

I never dreamed that bzr would make such a difference to the Leo
project. The energy level and the level of collaboration are both
markedly greater today than they were a week ago. We now have a true
partnership of developers. This has been one of my dreams for Leo.

The more I play with branches and merges, the more opportunities I
see. For instance, as we get closer to an official release, I can
create a branch for the release that only I can push to. There is no
great need to be careful with the trunk.

Indeed, the question of when to merge doesn't seem all that
important. You can merge whenever you want. It's no big deal if
sources get temporarily out of synch: another merge is usually all
that is needed.

Edward

P.S. My present preference is not to create branches for small changes
like bug fixes, but perhaps that is only because I usually am the one
fixing bugs. A branch for the new Vim plugin, for example, seems
reasonable: it is a snapshot of an improvement. It's self contained,
and can easily be diffed against other branches.

EKR

[Edward K. Ream]

On Apr 9, 5:33 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> I never dreamed that bzr would make such a difference to the Leo project.

It now seems to me that bzr does for backup what Python did for
programming. In my white paper about Python, I mentioned Python's
safety:

http://webpages.charter.net/edreamleo/whitepapers.html#safety

Last night I realized the same kinds of remarks apply to bzr. It
doesn't matter how many branches are created, or the order in which
they are merged. Nothing is dangerous, except possibly not creating
branches to hold intermediate work. :-)

For example, I have just created a sax branch. It contains last
night's work removing all non-sax code from Leo's fileCommands read
code. Last night I could just blast away this crucial code. No
worries. I was working in the devel branch, but when it became clear
that the project was going to take more work, I just pushed what I had
to the sax branch. Now I can revert (pull) the devel branch if I
like, and work on the sax branch at my leisure.

In essence, bzr makes it possible to delay decisions about what
branches should, or should not, be created, and decisions about what
code is, or is not, safe to release. None of the choices are final:
they can always be modified later.

The *effect* of bzr is that I can work on multiple branches
simultaneously. Never again will I worry about what "should" come
first. I'll just do my work, save to branches, and decide later when
and how to merge into the ekr-devel or trunk branch. This is my idea
of complete safety.

Edward

[Kent Tenney]

A related blog post
http://griddlenoise.blogspot.com/2008/04/what-dvcs-gives-me.html

[Edward K. Ream]

On Thu, Apr 10, 2008 at 8:02 PM, Kent Tenney <kte...@gmail.com> wrote:

A related blog post
http://griddlenoise.blogspot.com/2008/04/what-dvcs-gives-me.html

Thanks, Kent, for this link.

Last night I realized there is yet another advantage to using bzr: instead of organizing Leo's to-do list in the order I expect to do tasks, I can organize Leo's to-do list by branch/project.  After creating a branch; I do tasks in whatever order happens to work.

I have spent *so* much time thinking about what it the "right" (most effective, safest, most productive) order to do tasks.  Now these choices get pushed into actual development.  This will lead to a big increase in productivity: I won't obsess about choices. In the context of a limited project/branch, most of these choices either don't matter much, or become clear while I work.

In short, creating branches localizes the scope of choices to small projects, thereby making those choices less important and more provisional.  A big step forward for Leo's work flow.  It's time to revise Leo's to-do list :-)

Edward

[Edward K. Ream]

On Apr 10, 9:30 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> The *effect* of bzr is that I can work on multiple branches
> simultaneously.

The code on the trunk now reports the "load" directory (g.app.loadDir)
in the log pane on startup. This information is more important now
that it is more common to start .leo files from many different
directories/branches. It's pretty easy to become disoriented if
multiple .leo files are open at once.

Edward

[Edward K. Ream]

On Apr 10, 8:02 pm, "Kent Tenney" <kten...@gmail.com> wrote:
> A related blog posthttp://griddlenoise.blogspot.com/2008/04/what-dvcs-gives-me.html

I've read this blog post several times now. I'd say all the benefits
apply to bzr too. Perhaps the most important thing to get from the
post is the sense of excitement, energy and freedom that come from
what would naively be thought of as a mundane tool.

Edward

[Edward K. Ream]

On Apr 9, 5:33 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> I never dreamed that bzr would make such a difference to the Leo project.

My strategy for what's next for Leo now often involves branches and
merges.

For example, I am about to create a sax-graph branch which will, as
the name implies, be a merge of the sax and graph-world branches. I
am creating a separate branch for this because the merge may be
complex: I want to retain the previous branches until I am sure that
the merge has gone well.

Thinking in terms of branches and merges is a much higher-level
strategy than was possible before.

For example, the sax-graph branch implies that the graph world will be
the basis of future work. The paste-outline command is the last piece
of the puzzle for the graph world. It is low-level code; it would be
wasteful to do it in the context of the old (non-graph) world, only to
redo it for the graph world. Much easier just to do paste-outline in
the graph world where the data structures are simpler.

I'll test the sax-graph branch for about a week before merging it with
the trunk. At that point, a great leap forward will have happened.

Edward