Describe your workflow

Thu Jun 26 15:02:48 BST 2008

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

Probably not exactly like git or hg. Just sort of a hybrid. I find 1
working tree to be too limiting, but having 40 of them to be a bit much. :)

I like that branches are locatable by path, but I also find contextual
paths to be very handy (being able to type "bzr switch feature" rather
than "bzr switch /path/to/feature"). At the moment, only 'bzr switch' is
contextual. We've generally tried to avoid it, because then you can get
consistent behavior regardless of where you run commands. I'm wondering
if we don't want to change that, though.

John
=:->

|
| On 2008 jun 25, at 17.41, John Arbash Meinel <john at arbash-meinel.com>
| wrote:
|
| 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

iEYEARECAAYFAkhjoYcACgkQJdeBCYSNAANzZACfQfka9/um61nVDdK66dNYJ/25
PX0An0XT7e/K7Z9h4P90R99xsDoXTrq6
=l4mY
-----END PGP SIGNATURE-----