> What about this approach is brittle?
Mainly because you would have to regenerate each and every patch each
time you made changes to any of the environments. Also, the patch can
only be applied to go from one environment to the other right?
So, you have a patch the brings you from Env A to Evn B. then I assume
you have one that goes from Env A to Env C. What if you wanted to change
from Env B to C or C to A? What happens if you want to add environment
D? The matrix of patches could get pretty unruly.
Also, if Env A is the one that is in svn and someone applies the patch
to bring it to Evn B... then their working copy has those changes in it,
right? They then have to be sure not to commit those files or then your
check in config will no longer be for Env A but for B. Then someone does
an update expecting to get Env A and that is not what they get. I hate
to have to make people thing and selectively make sure they don't commit
these evn files.
So, if there are many files create a folder for each set of config
files. Same idea as what I said for one file. I was also thinking that
you could maybe do this with enterns and have a copy of each env as a
separate branch pointing to the correct config folder as an externs.
But, that would be more trouble because now you would have to keep all
those brances in sync by merging all the time... and make sure dev is
only done in trunk.
Also, if you are on linux you could just create a symlink to the correct
config files and have a batch file that set the correct symlinks. (Can't
do this on windows) The bottom line is switching to a new environment
does not cause the working directory to be dirty.
BOb
________________________________
From: carrolky_at_gmail.com [mailto:carrolky_at_gmail.com] On Behalf Of Kerry
Carroll
Sent: Thursday, November 13, 2008 5:05 PM
To: users_at_tortoisesvn.tigris.org
Subject: Re: using patch to manage differences
Bob,
What about this approach is brittle? My goal is to have the exact same
files in all three copies. As new versions are introduced, the
identical settings need to exist in each copy, save for the environment
specific settings. In my mind at least, this is what a patch should do.
Also, there are actually about 27 different files in C and about 16
different files in B (A and B share some settings that C does not).
These files are in multiple separate folders. This is why capturing all
of these differences in a separate file that could be used to recreate
the environment (e.g., a patch) seemed so appealing.
Kerry Carroll
carrolky_at_alumni.uc.edu
Received on 2008-11-13 23:29:32 CET