Will Merrell wrote:
>
> Thank you to each of you. That solves my immediate problem. Since the file
> involved is one that is seldom changed and is buried deep in the project
> directories, that solution will work fine for me.
>
> However, if I had a situation where this involved a large number of files,
> the duplication involved in having a bunch of template files around could be
> anoying. I would offer that there may still be a use for the kind of feature
> that I originally mentioned. The solution in the FAQ will work for me, but
> it is still a work around and there may be a better solution available with
> a little tought.
>
Having thought about this a bit, I agree that there is a real reason to
add new functionality here. There method of using a template is
basically just a workaround, and while it does suit a number of
situations, it isn't suitable for all; and even in those situation it
does suit it introduces a number of gotchas.
Consider that situation that we have: a (PHP) config file. This file
sets a number of variables that control the operation of the system as a
whole. We store the file as a .template file with a number of default
values and developers copy this to the correct name (say config.inc).
Job done.
That gotcha in this case occurs when you add a new value to the config
file. Adding these to the developer's own file then becomes a manual
process, and requires that they are either told that the change has been
made or for them to just notice that things don't work any more. Then
there's the problem that developers might add the new change in a
slightly different place to the position in the template, so over time
the files go out of sync.
The optimum solution is what I believe has been mentioned: a svn
property (e.g. svn:no-commit) that tells subversion not to commit the
file unless a flag is passed to the commit command (e.g. --force). The
benefit of this is that when new options are added to the file the
developers automatically get the change merged into their file in the
same place when they next do an update.
--
Russ.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 20 16:09:06 2005