[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: Sparse Directories vs Externals

From: void pointer <rcdailey_at_gmail.com>
Date: Wed, 25 Feb 2009 16:04:17 -0600

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.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 23:05:10 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.