Recommended use of Bazaar for single-committer multiple-machine projects?

[John Arbash Meinel]

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

Mary Gardiner wrote:
> On 2008-12-12, Mary Gardiner <mary at puzzling.org> wrote:
>> Andrew Bennetts told me that his understanding was that for the
>> kind or project I'm using this for checkouts are a better design for
>> exactly this reason (even if ).
> 
> "... even if the implementation is buggy" (I am told the Bazaar team
> themselves, who are of course not a sole-author or primary-single-author
> project, don't dogfood them for Bazaar itself).
> 
> -Mary
> 

That depends what you mean...

The actual bzr trunk is managed by a script, which ensures that the test
suite passes before a commit is allowed. This turns out to be rather
useful, as it is easy for a human to think something is trivial, and
decide not to wait before committing, only to find out later you were wrong.

That said, I personally used heavyweight checkouts into a treeless
shared repository on another machine for a long time. And I still use it
for certain things. (As Robert mentioned, all my plugins are heavyweight
chekouts.)

I don't use 'commit --local' and don't particularly like the design.
Especially considering how it interacts with things like "bzr update"
when you have some local commits, and some uncommitted changes, etc.

When I use a heavyweight checkout, that is because I explicitly want to
make sure that the branch is a mirror of the source. If I was to go
offline, and want to commit, I would "bzr unbind", and then "bzr push &&
bzr bind" when I came back online.

I don't think my workflow is optimal for everyone, but I can give you my
layout if it gives a viewpoint:

~/dev/bzr
	A shared repository for everything underneath, this is actually
	a "no-trees" repository, though I have explicitly created a
	working tree for some of the branches underneath.

  bzr.dev
	A heavyweight checkout of http://bazaar-vcs.org/bzr/bzr.dev
	I use this as the code whenever I run "bzr XXX", which means I'm
	dogfooding the development tip pretty much at all times.
	I actually use a checkout of a readonly source intentionally,
	because I *don't* ever want to commit in that directory. It is
	my "pristine" copy of upstream.

  jam-integration
	A heavyweight checkout pointing to my server. I use this for
	making 'trivial' changes, or when I go to submit changes to PQM
	for other people.
	Here I use a heavyweight checkout because I know that when I'm
	done doing "bzr commit" the changes have been mirrored to my
	public location.
	If we didn't use a PQM, I would probably not have this, and
	instead "bzr.dev" would be a checkout of a writable location.
	The idea is that I have a place for "trivial" work, that I don't
	want a separate feature branch for.
	I also have "jbzr" aliased to jam-integration/bzr so that I can
	quickly experiment with things.

  1.9/
  1.10/
  1.11/
  ...
	A bunch of simple directories, which I use to organize my
	feature branches. They are loosely grouped into the expected bzr
	release in which they will land.
	The location here also maps directly to the public location
	(1.11/foo will be mirrored to http://..../1.11/foo)
  work
	A lightweight checkout pointing at one of many different feature
	branches. Such as ../1.11/foo.
	I have "wbzr" aliased to "work/bzr" so again I am able to
	experiment with the new code without having to remember a
	cumbersome path.
	In a given day, I tend to do something like:
	  cd ~/dev/bzr/bzr.dev
	  bzr up
	  cd ../work
	  bzr branch ../bzr.dev ../1.11/new_feature
	  bzr switch ../1.11/new_feature
	  # hack, commit, test, commit, etc.
	  bzr push # mirror this to my server to make sure it is
		   # publicly available. I have a default push location
		   # configured, so that the feature branches always
	 	   # get pushed to the correct place without me needing
		   # to think about it
	  bzr send -o ../patches/new_feature.patch
	  # email bzr mailing list with new_feature.patch
  alt_work
	Just another "work" directory, because I often have multiple
	feature branches "in progress"

At one point, I used exclusively heavyweight checkouts to my public
location. However, the time for ssh to connect is quite noticeable when
you commit often, and I found that having that delayed until "bzr push"
was an acceptable tradeoff of the likelyhood that I would forget, versus
the time spent waiting for commit to finish.
Also, when you are working on a lot of different branches (current count
is 76 on this machine and 475 on my server), having a separate full
working tree for each actually starts consuming a noticeable amount of
disk space, and creating a new one means building all new files so it
takes seconds instead of happening almost instantly.

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

iEYEARECAAYFAklC0oAACgkQJdeBCYSNAAP6zQCeL5ARisIfl6F8u6RDmNzTIcjH
xx8An30YBMW0i0Buznx1LE1CRoEXEon8
=15BO
-----END PGP SIGNATURE-----