views:

176

answers:

3

So my team is just starting to use branches on our project, and we've run into an organizational issue concerning the way Eclipse/CVS handle branches and projects. My question is this:

Is it possible to ensure that multiple projects are always synched to the same branch with CVS in Eclipse?

Here's a simplified scenario:

Two projects: ProjA and ProjB, and two branches: Dev and Release.

So let's say both projects are synched to Release in my workspace, and I decided to add a new feature. I only anticipate that this feature will touch ProjA, so I naively branch only that project to Dev. So now my workspace is inconsistent.

After a few hours of work, I realize that I need to make a small change to ProjB, so I pop open the file in question and make my change, forgetting to sync it to Dev.

Later, after my changes are complete, I commit them. Now, I've just committed the changes in the first project to Dev, and the changes in the second project to Release. Woohoo, broken build!

A solution to this problem would either:

  1. not have let me sync the two projects separately
  2. not have let me commit to two branches at the same time

Now, in the real world, we have about 30 projects, and a number of developers working on feature branches, many of whom seem destined to use branching to break the build any way possible. I'd like to remove some of those ways.

+1  A: 

Is changing vcs an option? Having recently transitioned at my work from cvs to mercurial, I don't think I could go back. I think that any of mercurial, git or bzr would solve those issues.

crazyscot
I've been fielding the possibility, but there's too much inertia at this point for the idea to gain traction.
Ipsquiggle
I posted an answer describing what we eventually went with. However, I'm accepting this answer as it seems like the one that is the most 'right' to me. ;)
Ipsquiggle
A: 

There are two approaches you can take here.

Name your Eclipse projects after the branch they're created. So if you're working on a feature branch for ticket number 123 dealing with ProjA you check out your Eclipse project as ProjA_123 (or ProjA_Dev if you wish). You can call your release branch ProjA_Release.

Alternatively you could maintain separate Eclipse workspaces for each branch.

So long as you have some system to identify which branch your working checkout is from, you should be fine.

NeilInglis
Right now I'm using the project decorators to boldly print the name of the branch a project is in beside the project name. This is very helpful is using the project browser, but less so if the developer ends up in the new project otherwise, e.g. using goto definition.
Ipsquiggle
Is it possible for multiple workspaces to deploy their projects to the same folder on the local disk?
Ipsquiggle
I don't think that's possible; why would you want to?The way that works for me is simply to have this layout:Workspace - ProjA_123 -> Checkout of branch 123 - ProjA_release -> Checkout of release branch - ProjB_444 -> Checkout of branch 444 - ProjB_release -> Checkout of ProjB release branchYou can check out the Projects from CVS multiple times, just giving them different folder names as they're checked out.
NeilInglis
Aaah, I see what you mean. Unfortunately, our tool pipeline depends on project location on the disk, so putting them in differently named folders would break that. (This of course, is it's own issue...) I appreciate the thought!
Ipsquiggle
+1  A: 

After much trial and research, it seems that because of the way branches are handled in CVS (that is, on a per-file basis), a scenario like the one I seek is not possible (at least not without some tool special-built to this purpose).

We ended up just going with a soft solution: By changing the color and format of the CVS label decorations in Eclipse to something more striking and isolated, it's much easier to casually identify which branch a project (or file) is synched to.

The Eclipse settings are found at Team > CVS > Label Decorations > Text Decorations and General > Appearance > Colors and Fonts > Basic > Decoration Color.

And, of course, implementing some best-practices along the way.

Ipsquiggle
This is itself an interesting approach. All of a sudden my head is full of memories of wise people telling me to solve social problems by social means, and technical problems by technical means - but I'm not sure sure precisely which box this problem falls into :-)
crazyscot