Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

John Arbash Meinel writes:

 > > Pardon me if I'm wrong, but all three of those requirements are met
 > > by lightweight checkouts of branches stored in a shared repository.
 > > [...]
 > > Roland.
 > 
 > Lightweight checkouts handle all the cases of colocated branches

No, they don't handle branch *creation*.  You need to have an existing
branch to "bzr switch" to.  Colo is like having an infinite number of
branches you can "switch" to just by naming them (but they have to
have a tip at an existing commit).

 > Our model is slightly more flexible.

Lightweight checkouts are more flexible in the sense of supporting a
truly centralized workflow, yes.  More flexible in supporting
distributed multiple workspace workflows, I really don't think so.  I
would argue less, for the reason given above.

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

s/multiple checkouts pointing at a collection of branches/clones/, and
that is exactly how I would describe using multiple clones in git.

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

That update I almost never want, anyway.  If I do want it, on a
particular occasion, "git push" is negligible effort.  If I really
wanted that behavior, I can almost get it by manipulating GIT_DIR (for
values of "almost" meaning "the necessary manipulation would require a
tedious bit of scripting and some adjustment to the UI but the
functionality would be the same"[1]).

I'm curious what your use case is for wanting the branch pointer to be
updated.  I would think that would be a recipe for massive confusion,
even if you did it to yourself (eg, in the use case you describe above,
if you commit in your Y repo, and your X submission gets rejected or
revise-and-resubmit, then what?)

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

Ugly?  Why?

 > So it would be effectively discouraged to do so by the UI.)

I hope not!  Colo branches and multiple checkouts are two somewhat
different use cases (see above), and it seems to me that it's in the
spirit of Bazaar to support them both.


Footnotes: 
[1]  Or maybe better since I do have a colo repo, and the problem of
an inadvertant commit either doesn't arise or is trivial to fix.  Ie,
with a pure ref manipulation: after inadvertantly committing in
workspace Y to branch X, just do "git branch Y; git reset HEAD^; git
checkout Y" and X is back where it belongs and the new branch Y is a
real branch in workspace Y and repo $GIT_DIR containing the right
changeset(s) -- with no change to the workspace or object database.