> On Apr 24, 2005, at 3:36 AM, Eneko Gonzalez wrote:
>> Nowadays, I have three development stages in my projects:
>> - development (several windows machines),
>> - testing (linux server) and
>> - production (linux server?).
Sounds like you are describing a promotion model. See "Navigating the
Ocean of Promotion Notions" at
<http://www.cmcrossroads.com/article/32900> for several different
implementation mechanisms and their tradeoffs
>> My idea is to have three branches: trunk (development), testing and
>> production, where i can have the configuration files prepared for each
>> environment.
>>
>> All the development should go to trunk brach, and testing and production
>> should be used (with tags) when we have a new release.
>>
>> -> żIs there another (and better) way to do this?
>
Tom Mornini wrote:
> Sure. Add a second extension to the config files (assuming they have one
> already) like this:
>
> program.cfg becomes:
>
> program.cfg.dev
> program.cfg.test
> program.cfg.prod
>
> Have a script that sets up the right files by mv'ing the right file
> to plain and simple:
>
> program.cfg
If all you really need here is the setup environment, then what Tom
describes above is definitely the first approach I would look at (and
one I would strongly prefer over branching)
If youre into object-orientation and/or refactoring, what the above is
essentially doing is introducing "polymorphism" or "dynamic dispatch"
into the build/setup scripts and "program.cfg" is the "base class" with
each of .dev, .test, and .prod being "subclasses" that all respond to
the same "setup" or "make" message in their own correct way.
There is a "refactoring technique" (see www.refactoring.com) commonly
known as "replace conditional with polymorphism" whereby a big
if-then-elseif-...-else (or case/swicth) block is replaced with a base
class, and then a derived subclass for each case.
What Tom describes is basically the same "refactoring" technique applied
to the build/setup scripts - and it is replacing the cases/conditions
for which you wanted to use "version branching" (rather than
control-flow branching) and instead using "polymorphism" in the form of
environment-specific configuration objects/files that all "conform" to
the same "environment-setting interface".
>> Besides, i want to know if this strategy would need a lot of free disk
>> space or not, as i'm going to have my project files in, at least, three
>> branches.
You will probably still need to use a separate "copy" (workspace) for
each of your three environments (dev, test, prod). But I would still be
inclined NOT to try and "branch" the same file in each workspace and
would instead do as Tom described, creating a separate
configuration/setup "object" (file) for each environment, along with
Make/Ant files and/or setup scripts that simply take (or can infer,
perhaps from the workspace "name") one of dev, test, or prod as a
parameter, and then "do the right thing".
To me, that approach is more reusable and component-based, and requires
no additional integration efforts due to branching+merging
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 26 08:43:29 2005