On Wed, Feb 25, 2009 at 1:17 PM, David Chapman <dcchapman_at_earthlink.net>wrote:
> 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.
These problems sound like they could be solved with continuous integration &
nightly builds.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1229176
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 23:05:10 CET