Bazaar Mercurial Plugin to access BitBucket

[John Arbash Meinel]

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

...

>> A third is where there are external things that depend on the 
>> location.
> [...]
> 
> Pardon me if I'm wrong, but all three of those requirements are met
> by lightweight checkouts of branches stored in a shared repository.
> I myself don't handle an astronomical number of branches, but I
> have my repository in ~/bzr-repo/, and the working trees are all
> lightweights under ~/$project/$tree.  I usually keep one tree
> constantly on the relevant "trunk" branch (with $tree=trunk),
> sometimes another on a specific branch I spend lots of time in
> (with $tree=maintenance for instance) and another is where I fool
> around (with $tree=switch). Inside that "switch" tree, I just "bzr
> switch $foo" whenever I change focus.
> 
> Roland.

Lightweight checkouts handle all the cases of colocated branches
(except multi-push at the moment, but conceptually they could). It is
how I have my work setup, and I use *lots* of feature branches.
(https://code.launchpad.net/~jameinel/bzr lists me as having 538 owned
branches of bzr.)

However, it isn't very streamlined to set up, so it generally doesn't
get brought up in discussion.

The biggest thing is that 'bzr branch $UPSTREAM' doesn't give you a
shared repository and a possible collection of branches that can be
accessed from a single working tree. You can set it up to do so, but
'git clone $UPSTREAM' gives you something right away.

Our model is slightly more flexible. I *really* like being able to
have multiple checkouts pointing at a collection of branches. So I can
have multiple development locations. So while I'm waiting for a review
of feature X, I can be hacking on feature Y. I don't have to commit
the state to switch another checkout back to feature X in order to
respond to review requests.

You can certainly do it in git, but you end up with another branch in
another location, so updating it in the second checkout doesn't update
the branch pointer in the first checkout, etc.

As part of the UI revamp, we'd like to address bits of this. I think
the end decision was to push more into co-located branches and live
with the loss of clearer multiple-checkout support. (If branches are
nested underneath your working tree in .bzr/branches, it is
possible-but-ugly to have a separate checkout of one of them in
another location. So it would be effectively discouraged to do so by
the UI.)

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

iEYEARECAAYFAk6ntukACgkQJdeBCYSNAANv2QCglKZaq2jB5Izn2Cj/QVGEvGx9
aX4An3mspuSbaiGk6ZRSvzxcY0ShNMuA
=wPTt
-----END PGP SIGNATURE-----