bzr-eclipse problem

[Neil Martinsen-Burrell]

On 2010-02-05 21:33 , Andrew Cowie wrote:
> On Fri, 2010-02-05 at 22:10 +0000, James Mansion wrote:
>> I've gone back to svn for my Java stuff for the moment - refactoring 
>> moves files around and its too painful not to have the IDE drive the VCS 
>> moves.
> 
> This is indeed the quintessential use case. You *can* do this with
> Bazaar, but its support for this scenario is somewhat forced.
> 
> [in that most of the Bazaar hackers live in a one-directory-per-Branch
> world of python where it's perfectly alright to have 10s or 100s of
> Working Tree checkouts. So cool, the best way to use Bazaar is with a
> lots of branches and no problem because you can just go an ./bzr there.
> That doesn't fly for the kernel hackers because of disk space and not
> wanting to rebuild an entire kernel just because you changed branches,
> and it doesn't fly for Java people because they can configure one *and
> only* one instance of a project (with it's given family of classes) in
> an IDE like Eclipse (otherwise you end up with Eclipse thinking it has
> 10s or 100s of versions of a each class, and you're screwed]
>
> ++
>
> The way we suggest people hacking on our project in java-gnome is the
> sequence described at the top of:
> http://java-gnome.sourceforge.net/4.0/HACKING.html

This use-case (many branches, one working tree) is the intended purpose
of the bzr-colo plugin.  It has been working very well for me and some
others for exactly this model of development.  It is essentially a way
of streamlining the creation of exactly the structure described there,
along with convenient commands to create, list and remove branches
stored in the shared repository, as well as a directory specifier colo:
to unambiguously refer to branches in the shared repository.

> This setup gives you a ~/workspace/project-name place where you can do:
> 
> $ bzr switch other-branch
> 
> and in combination with:
> 
> $ bzr mv --auto
> 
> things are somewhat better. It's all still very cumbersome compared to
> Git, but it's ok if you're careful to work within the limitations of
> this setup.
> 
> The problem isn't Bazaar supporting this; clearly it does. The grounds I
> would cite for considering this worthy of improvement are 
> 
> a) it seems a bit of an afterthought / bolted on the side. It wasn't
> what bzr was for originally, and it still seems a bit of a fringe use
> case; and
> 
> b) it's a bit fragile, because if you do any of a number of perfectly
> normal bzr commands you can easily screw up your setup.

Can you say more about how this setup can get screwed up?  I'd like to
check for these situations in bzr-colo.

-Neil