Describe your workflow

[John Arbash Meinel]

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

Paul Hummer wrote:
| Aaron and I were chatting about shared repositories the other day, which
| just triggered a discussion with Tim about his workflow.  I'm curious to
| know other's workflows using bazaar as the VCS so that I can find
| something that might work better for me.
|
|   - How are your folders laid out?
|   - Do you use lightweight checkouts?
|   - What plugins could you not live without it?
|
| Your input is appreciated,
| Paul

I traditionally have done heavyweight checkouts into a local shared
repository towards my local network shared repository. So I would
basically have done:

bzr init-repo --trees work
bzr init-repo --no-trees bzr+ssh://host/public/

And then did stuff like:

cd work
bzr co http://upstream/bzr.dev


And at that point, I would configure things so I could do things like:

cd work
bzr cbranch bzr.dev feature_branch

Which would branch to bzr+ssh://host/public/feature_branch


And then commits would auto-publish to my public repo. I actually had a
slightly more involve structure, because I have a lot of branches. So I
would do:

~ ~/dev/
~    bzr/ <= repo here
~      bzr.dev         <= A couple "main" branches here
~      jam-integration

~      1.4-dev/ <= Branches expected to land in ~1.4
~        feature1
~        featuer2

~     1.5-dev/ <= ditto ~1.5
	featureX
	featureY

In general, this works decently. It is a bit slow to create a new branch
because you have to build another working tree, and commits always push
to the shared location. Which is good that they are being mirrored, but
it does slow down "bzr commit" a little bit.

It also starts to consume a surprising amount of disk space, just due to
the working trees. A fresh bzr.dev checkout is about 14 MB. Once you add
in-tree build products and .pyc files, you end up with ~27MB. (And if
you build releases there, it goes up to about 80MB).

I just counted, and I have 36 feature branches lying around. Most of
them have probably been merged, and I can prune them, but if you have
30+ feature branches which I've run "bzr selftest" in, you end up with
27*30 = 810 MB.

So suddenly for working on a relatively small project, you end up with
almost 1GB of disk space consumed for just the working trees. (Note that
in all of this, my repository is nicely sharing and sitting at only 98MB
consumed space.)


So I decided to start trying 1-working-tree multiple-no-trees branches.
Aaron will probably cry with my layout, but I use:

bzr init-repo --no-trees ~/dev/bzr

cd ~/dev/bzr
bzr co http://bazaar-vcs.org/bzr.dev

# This is my pristine upstream checkout, notice that it is a checkout of
# a read-only branch, so I don't let myself get lazy and commit there,
# and it has a working tree (I actually have my default 'bzr' point
# here, so it is important to have it available.)
# I also use it all the time as a reference code.

bzr co bzr+ssh://host/public/jam-integration

# I also leave a checkout of just "jam-integration", as I use that
# fairly often to bring in people's patches to submit them to PQM.

bzr branch bzr.dev 1.6-dev/feature-XXX

# Note that because of --no-trees, this is super fast, and takes very
# little disk space. Probably the biggest consumption is just that we
# have 8 very small files for every branch. so the wasted space is a bit
# high.

bzr co --lightweight 1.6-dev/feature-XXX work


So at this point, I have a lightweight working tree at ~/dev/bzr/work
which points at whatever I'm actively working on at the moment. I
configured my bash shell to add $(bzr nick) to the prompt, so I can tell
what actual branch I'm working on in that directory. (That was the
biggest thing I missed after switching to an all-in-one dir.)


I've also found that sometimes I need more than one "work" location,
because I'm doing a quick bugfix, and need to set aside my
not-ready-to-commit work. But that is just another "bzr co --lightweight
away".

To create and switch to a new feature, I do:

cd ..
bzr branch bzr.dev 1.6-dev/feature-YYY
cd work
bzr switch feature-YYY

And I'm ready to go.

It's really nice to have the build products in directory, so I don't
have to run "make" every time I start a new feature (or for some
projects, just that the 'make' run would re-use most of the intermediate
steps.)


I also have a default push location set up, so that I can do:

cd work
bzr push

And it picks up where the branch is, and pushes to
bzr+ssh://host/public/.../1.6-dev/feature-XXX

Which is great. The only problem is that you have to edit
~/.bazaar/locations.conf in order to override the "default" push
location. (push --remember sets it in .bzr/branch/branch.conf, which is
overridden by any setting in ~/.bazaar/locations.conf)


Overall, I'm pretty happy with this layout, having a stable location to
work in also means that I can create a quick shortcut to "wbzr" (working
bzr) and quickly test it out. Eventually, I'll probably wish that "bzr
switch" allowed multiple levels, so I could do "bzr switch 1.7-dev/foo",
but I haven't run into that yet.

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

iEYEARECAAYFAkhiZyMACgkQJdeBCYSNAAM9twCgga5hLYJyYeSRcSpFWL9LF6ZB
mtkAn1KRs7HzyFS+Pqr6dgBohnI5g2Cj
=fqCT
-----END PGP SIGNATURE-----