On 11/2/07, Les Mikesell <firstname.lastname@example.org> wrote:
> Nathan Nobbe wrote:
> > On 11/2/07, *Bicking, David (HHoldings, IT)*
> > <David.Bicking@thehartford.com <mailto:David.Bicking@thehartford.com>>
> > wrote:
> > This sounds to me like "branch by task", but we're not necessarily
> > talking about large tasks, and we don't want to branch frequently
> > alone have each team member branch for each of their tasks).
> > what dont you like about the notion of braching frequently ?
> Branches isolate people's work. How do you cooperate when the changes
> affect each other?
working in isolation can be advantageous.
its the same paradigm as trunk / branch.
think of it as adding another tier
trunk / branch / twig
just use the same tools for moving code between the branch and the trunk.
consider the branch as an integration environment for multiple developers.
developers dont push to branch until they are ready for a code review say.
then if the review shows the code is making integration unstable svn cp
it to an earlier revision. if at any time a developer needs code that was
recently added to the integration environement (branch) they merge it into
the benefit is the branch can remain stable most of the time. also, you
another working area where you can decide what will get promoted into the
final product, which is the trunk. say a feature is developed, passes
and makes it into the integration environment. now suppose, the feature is
removed from the list for w/e silly business reason; simply dont merge it
smaller environments can simply use the trunk / branch model.
they way we do it here is as follows:
we all work out of the branch. then we svn merge into a working copy of the
trunk. only after review do we actually commit to trunk. the only real
is new files get added to the trunk irregardless, unless we want to scp them
over to the working copy of the trunk which we deemed too much of a hassle.
this is why i like the 3-tier model more, but that has its own overhead.
Received on Fri Nov 2 21:35:30 2007