[news.eclipse.tools] Re: eclipse, cvs, and a central integration machine

[Eric Rizzo <eric.rizzo@xxxxxxxxxxx>]

JLM wrote:

> > Hi all -- I Haven't been able to find a discussion about this topic: Has
> > anyone implemented an extreme programming-style central integration 
> > machine,
> > with a serialized integration process?
[snip]
> > Now we're ready to move to Eclipse since we all use it in our side 
> > projects,
> > but the only thing we have a big question about is how to implement the
> > central integration point using CVS -- does anyone have experience doing
> > this?  Do all developers, for example, refresh their local machines 
> > with the main trunk code,
> > then immediately create a branch locally for their current
> > work, then merge it into the main trunk at integration time?
> >
> >  This seems
> > like the most logical thing to do, implementing the rule that no actual
> > development is done on the main trunk
> > -- it is always the "master image",
> > and development happens on the branches.  But, since we haven't 
> > tackled it
> > yet, we're not sure.

Of course you'll have to try some things to see what works for your 
team, but here's what we do that works pretty well for us (I'm pretty 
sure this is common practice for CVS-using teams). Note that we are not 
doing XP, per se.
We do most work on the HEAD (trunk), but create branches for two reasons:
1) A "release," meaning something that gets production-built and posted 
as a public version of the application. We label and branch at each of 
these releases, so that maintenance work on that release can happen in 
parallel with "new" development for the next release

2) If a developer is working on some new work that is either very 
disruptive, very backwards-incompatible, or is likely to take more than 
a day or three. For such tasks, we often create a branch so that work 
can be checked in without causing headaches for everyone else. This is 
not a very good practice in an XP environment, since it is not sticking 
with continuous integration (strictly), but it is realistic - sometimes 
there are tasks that would disrupt too much of the code and it is easier 
just to merge them in once they are finished. A recent example of this 
with our app was upgrading from JDK 1.3 to 1.4. If the entire team is 
aware when such a branch is being worked on, they can keep in 
communication with that developer to minimize conflicts with other work 
on the HEAD.

But other than those two reasons, we do all development work on the 
HEAD. Sometimes fixes on a release maintenance branch need to be merged 
into the HEAD, and we have begun using patch files to make that easier.

One final note: when you have branches, try to avoid merging in both 
directions to/from the same branch. IOW, if you have FooBranch and HEAD, 
either always merge from the FooBranch to the HEAD or vice versa, but 
try not to merge FooBranch -> HEAD one time and later HEAD -> FooBranch. 
In our experience, that can make merging later a real PITA (even with 
the awesome merge capabilities in Eclipse).

HTH,
	Eric
--
Eric Rizzo
Software Architect
Jibe, Inc.
http://www.jibeinc.com