RE: Re: Re: using patch to manage differences

I am just giving one mans (mine) opinion. As I said, I wouldn't do it
this way... but as you know of course this is your system not mine.

One other thing I would say is if your devs are only using 1
environment... (what I would do) is have that be the checked in one...
they have my build scripts modify the environment as needed for the
different deliverables.

YMMV,

BOb

________________________________

From: carrolky_at_gmail.com [mailto:carrolky_at_gmail.com] On Behalf Of Kerry
Carroll
Sent: Thursday, November 13, 2008 6:16 PM
To: users_at_tortoisesvn.tigris.org
Subject: Re: Re: using patch to manage differences

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