Describe your workflow

[Erik Bågfors]

Looks like you want branches to work like they do in git or hg? This  
is the first time I've understood why anyone would like that. ;)

Regards / MVH
Erik

Sent from my iPhone
+46 730 808013

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

> -----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-----
>