David Chapman wrote:
>
>> 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.
If you each make more than one change, shouldn't the point be to find
how each specific change affects performance more than the ownership of
the code?
> 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".)
Is there some point to testing head/trunk, knowing that's not a
reproducible state? Your "If there's a commit" question doesn't make
much sense. Shouldn't your regression be running against a branch or
tag made for the purpose - or at least a specific revision of trunk?
There are plenty of ways to get reproducible results, but trunk/head
isn't one of them.
> 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.
Why can't you get any revision you want back from CVS? And why didn't
you have tags at the likely places you'd want?
> 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.
I don't understand. Are you saying you actually broke CVS with a commit
or that you couldn't do what you want with a known revision? Or that
since you didn't tag, you didn't know which revision to get?
> 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.
With CVS you probably needed to tag 'expected good' points while the
trunk advances, knowing the head may be unstable at times. You can do
the same in subversion or branch for testing/release - or you can do the
reverse and branch for development but it just seems natural to expect
development and changes to be happening on trunk/head and specify a tag
or revision number when you want something predictable.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1228465
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 20:45:57 CET