David Weintraub wrote:
> There are two theories on how development should be done.
>
> Method #1 -- the way your co-worker believes: You have two "streams",
> a development stream and an integration stream. Developers create
> their own independent development stream off of the integration
> stream, do their work, and then merge their changes back into the
> integration stream when completed. Advantages: Developers work in
> their own world that is unaffected by other developers. Disadvantage:
> Developers work in their own world that is unaffected by other
> developers.
>
> Method #2 -- The right way: Developers work all in the same stream
> which is where the code lives. This forces developers to work
> together, make sure they know what everyone is doing, and take small
> bites of code changes.
>
Don't try to speak for all of us. I learned very quickly when writing
optimization software that private branches are a Good Thing. Otherwise
my results (which took hours to compute) were constantly polluted by
seemingly harmless updates from other members of the group. Yes,
merging from trunk and reintegrating at the end of feature development
were not fun, but it was a lot better than trying to determine, every
day, which of the daily changes (mine or a colleague's) caused a
degradation in results.
We also had our share of partial commits to trunk, especially at the end
of the work day. Since developers' schedules were not always the same,
a workspace update at the start of the work day might result in a couple
hours in which the workspace was unbuildable or would fail on numerous
regressions. Since the full regression suite took hours of time on a
server farm, it was impractical to run them for every commit (or even
every hour). Even the developer's regression suite required an hour of
CPU time (and a minimum 10 minutes of clock time even on a server
farm). If there was a commit while the regression suite was running,
then what? (Our answer was "update, recompile, and commit your changes,
but then rerun the developer regression suite immediately".)
Since we were using CVS, when a bad commit by another developer messed
up a workspace we were stuck - reverting to a previous revision wasn't
possible. We had a binary search script that could determine which
commit caused the problem, and we had home phone numbers, but it still
took time to resolve these problems.
In short, there is no One Right Way. For agile development with
"shallow" code, development in a single line is probably better. For
optimization code that uses "deep" algorithms, private branches work
better. Branching in CVS was painful enough that developers often had
all their changes on their local hard disk for days on end; Subversion
would have made this much easier to deal with.
--
David Chapman dcchapman_at_earthlink.net
Chapman Consulting -- San Jose, CA
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1228334
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 20:18:29 CET