On Sun, Feb 22, 2009 at 11:14 AM, void pointer <rcdailey_at_gmail.com> wrote:
> He states they are "error prone", however I was not able to get any details
> on that out of him. I know in the past he has liked to work exclusively out
> of a branch and simply merge over his changes to trunk whenever he completed
> something (like a feature or bug fix), then delete his branch and recreate
> it for the next thing and rinse and repeat.
Already, I don't trust this co-worker. I bet he use to work with ClearCase.
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.
Most version control systems are meant to use Method #2, and that's
the way Agile Development is suppose to work too. It seems counter
intuitive that allowing for everyone to work like that produces better
code, but it does. People have to be careful and know it. People are
forced to coordinate changes they are working on. People know they
aren't suppose to change class methods willy-nilly because it causes
everyone else's code to break.
One of the few that uses this idea of private branching is ClearCase
which is why I think your coworker use to use ClearCase.
By the way, other areas of society are finding the same thing out:
When you separate everyone from each other, you actually create more
of a problem. Recent experiments in transportation engineering found
that eliminating stop signs and sidewalks actually produced fewer
accidents in neighborhoods. Drivers are more cautious. They never
assume they have the right of way and can go zooming down the street.
There are fewer pedestrian accidents because drivers have to watch out
for them.
As for using externals: Your engine is exactly what externals were
meant for -- a separate subproject that is used in multiple other
projects. My only suggestion is that you create a pre-commit trigger
to prevent people from changing the engine as if it was simply part of
their normal project.
I would also use a continuous build system like Hudson, and any time
the engine is changed, rebuild all projects that depend upon the
engine. That way, if someone does make a change, and it breaks all the
other projects, you can get it fixed immediately.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1221280
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 17:08:14 CET