<snipped>
> working copy. However, it would be nice for developers to be able to
> customize these config files to work with their system. If the
> developers do this, the modified config files get committed whenever
> the developer commits their next revision. Then when another developer
> goes to update their working copy they get the new (customized) config
> files and have to re-configure their config files.
<snipped>
While not directly dealing with your "ignore" request, we have a similar
situation wr2 multiple developers, environments & customized config files
for building, but we've got a different way of handling the problem that
avoids the conflict you've identified, yet allows us to preserve all the
customizations for each environment.
This has worked for the projects where we've used Ant as the build tool.
Briefly, our build scripts for a given project don't change across
environments (e.g. machines belonging to bob, joe, ted, or for qa, dev, or
prod). We've externalized all environment-specific settings to separate
data files, all of which are uniquely keyed by name to their environment
(e.g. bob.settings, dev.settings, etc.). Each system where we do a build
has some environment variables set that identify it so that the build
script picks up the identifying value as it starts up and uses it to pick
which settings to continue execution with.
e.g.
start a build on bob's machine.
build script picks up identifier 'bob' from the local OS environment.
build script slurps in the 'bob.settings' file and uses bob's settings to
build with.
Advantages:
- build scripts don't have to change for a project across environments.
- any truly special behavior, like some special logic for a production
build, can be built into the script and executed or not because the script
"knows" what it's building against and can branch its logic accordingly.
- everybody can preserve their custom settings in source control, nobody's
settings have to be 'ignored' (and subject to loss).
Obviously, you have to work out a system of unique identifiers for each
environment, but there's lots of ways to do that. We're not a very big
shop, so names, initials, and abbreviations works for us, but you could
use hostnames, for instance.
When I'm checking out or looking at status of the project, it's irrelevant
but harmless if bob's settings are up to date on my machine or not, it's
only important to me that mine are up to date, but both bob's and mine are
in source control as part of the project. If I lose my machine for any
reason, that's one set of configurations I don't have to try to remember,
at least. In our repository, each project has a couple of folders that
contain all these settings files - just used to build with - so they don't
clutter up the rest of the project tree.
for the record, i can take no credit for any part of this system -- some
other guys here figured it out and set it up. it's simple and has worked
well for us across a large number of projects for the last few years.
perhaps you might find a similar approach useful.
good luck.
regards,
-fj
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 29 06:38:30 2007