On Thu, Nov 13, 2008 at 5:28 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
> *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? *
>
Not sure I agree with this. We will only makd changes to Env A. Only when
we are prepared to make a new tag would we need to update the patches for B
and C (and D and E at some potential future point).
> *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.*
>
Again, we only go from A to B or A to C.If we added D, we would have to also
go A to D. The increase in effort is linear, but we do not expect to have
more than a few Environments. This again is why we want a process that is
relatively quick and reliable.
> *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.*
>
This I agree with. If someeone applies the patch and commits the change,
this could be problematic. Fortunately subversion retains prior versions,
though ensuring that this has not occurred will require some manual effort.
Realistically we don't expect to use this feature except when creating new
tags. This process will generally be applied by the change manager, not the
developers.
> 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.
>
If I understand correctly, externs only works on subfolders, not files
(correct?). Originally this was exactly our idea until we learned that
externs was limited to folders. Again, since these files are in so many
separate folders (and subfolders) I'm not sure we'd want to attempt to
duplicate this structure for two, three or more environments.
To your prior point however, no reason the patches couldn't be stored in a
separate folder and only made available to the change manager through an
svn:external property. That would reduce the chance that an ordinary
developer would stumble across the patch and apply it carelessly.
> 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.
>
Unfortunately this is not my call. I'm stuck on Windows.
Thanks for your suggestions though. Anyone else?
--
Kerry Carroll
carrolky_at_alumni.uc.edu
Received on 2008-11-14 00:15:52 CET