Using one working tree

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been playing around with using bzr in the "one tree, many branches" mode.
And I thought I would compile some of my experiences with it.

1) The very first thing that happened, is that I missed seeing what branch I was
in in my command line. I use a prompt like:

jameinel at samus ~/dev/bzr/work
$ bzr foo

And seeing plain "work" didn't give me any indication of what I was supposed to
be doing. I don't think I'm unique in having multiple branches "in flight" at a
time. Though others may not do it quite as much. (I usually have at least 5
branches in various states, often just waiting review and final merge.)

Looms don't really fit this way of working, because the work isn't built on each
other, they just were developed around the same time.

So the first thing I did was hack up my prompt to include $(bzr nick) as part of
it. I actually did a bit more, in that I give nothing if there is on nick, etc.
I'm also under cygwin, where 'bzr nick' can take 300ms or so (most of it is
bzrlib startup time). When it gets into 500ms it starts to be noticeable (note
that just starting python is >100 ms). So I added a tiny bit of caching so that
a new prompt normally takes < 100ms, which I don't notice at all.

So now I have:

jameinel at samus ~/dev/bzr/work {make-branch-and-tree-fix}
$


2) Using 'bzr branch' to create a new branch and then switch to it, is a bit
more cumbersome that it has to be. Right now I do:

bzr branch ../bzr.dev ../1.6-dev/new-feature-name
bzr switch new-feature-name

I'm not sure what we could do to make this easier. I generally don't want to
branch from what I'm working on right now, which may not be as common for other
people. I want to branch from upstream.

The *good* parts of it, is that 'bzr branch' is super fast, because I have no
working tree to build. (Also because I started working local only, rather than
always using checkouts to my server.) The 'bzr switch' is a bit slower, but time
here depends heavily on the number of changed files between the switch revisions.

Switching between existing branches is fairly fast, and the context sensitivity
of switch is quite nice. As these are local ../1.6-dev/xxxx isn't bad to type.
But typing sftp://....... urls would be prohibitive.

3) It is nice that I don't have to run "make" to rebuild the extensions whenever
I switch.

4) The biggest downside is that 1 WT really isn't enough. I have at least 1
pristine upstream tree (which is what I actually use for 'bzr'). It also gives
me something that I can quickly go "how did upstream do it... vi
../bzr.dev/bzrlib/xxxxxx".

I will also often have a "work-in-progress" and then want to do a quick bugfix.
Having to commit just to switch to a bugfix branch isn't very viable. So I also
have a ~/dev/bzr/bugfix working tree. (Meant for things that are going to be 1
quick commit, versus "work" which is stuff that will take a while.)

It still is a bit limiting to work on several different long-term features. But
it a way that is a good thing. It helps focus me on finishing this feature
before I plug away on the other one.

5) Did I mention that the overhead of building a new working tree, as well as
"make" is gone? (very nice) Also, I've saved a considerable amount of disk
space. A bzr working tree with .pyc files and build products is 23 MB. I have
about 50 branches on disk at this point. Having a WT in each was taking 1GB of
disk space.

6) Having my fixes for 'bzr log --short -r -10..-1' in bzr.dev also makes it
nice when I context switch. "bzr switch other-branch; bzr log" gives me a nice
reminder of "oh yeah, I was working on XXX" and it completes in just a couple
seconds. (bzr log is less than 1s, switch is still about 2s, which is a bit more
than I would expect.)

according to --lsprof all the time is spent in "compute_transform", with most of
that being 62 calls to "merge_contents", which has to extract the texts from the
repository. However, there is only 2.1s in knit.get_line_list, while there is
3.5s in 'compute_transform'. So there are other bits of overhead going on.
Again, according to lsprof of the 2.1s to actually extract the texts, 1.5s is
spent reading the index to figure out where and what bits need to be extracted.
So we spend 3x longer to figure out what to extract, then we spend actually
extracting. (but lsprof penalizes the bisect search code more than I think is
actually fair.)

7) switch does some weird things if you have new directories, because of having
"cruft" accumulate in those directories, it doesn't remove them. So when you
switch and switch back, you can get a conflict on that directory (and when you
switch it shows up as something to be added.)


Anyway, these are just my notes from now. Overall, I think it works fairly well
(especially with the context sensitive switch). I'm not sure the answer for
directories we can't clean up....

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhQPUsACgkQJdeBCYSNAAMYhQCcDF/tjazTAMXui+c+xhPgwqN1
6oMAoI70vxq14uIc83RFoNWN9WOwMxx8
=FRE8
-----END PGP SIGNATURE-----