blackhole_at_collab.net wrote:
> Thanks David,
> A deploy script is not a good solution in this scenario.
> Say I have 50 websites using web.ini. I create the websites and modify each web.ini to suit each individual site. Now, a new parameter is added to web.ini. At the moment I would have to edit each web.ini file in all 50 sites.
> It would be practical if I could do a svn update in each site and bring in the parameter (with a standard value) in each site. That make sense.
>
> The above would require the web.ini to be part of the repsotiory, however, in the sandbox, the web.ini in each site cannot be commited! Since that would overwrite all default values in the repository.
>
> In short, it would be nice if there was a feature where one could exclude files from commits, but allow them to be updated. That way, if a parameter is added to a ini file, all ini files (at production) could be updated with this new addition. Running a deploy script only works for something that never will get additions. If there are anticipated additions to a file, having them outside the repository is not a good solution since it will require someone to manually bring in the additions.. if we are talking about50 sites it could be done, but what about if we have 500?
>
> Maybe the above solution is already there?
> Is it?
I don't know of anything native to SVN, but in terms of workflow you
could declare web.ini as the systemwide defaults, and have your code
look for a second file - but run happily without it - with *just* the
site-specific changes to those defaults.
I've done this on a number of bits of code I've written, although
nothing particularly time- or CPU-intensive.
-kgd
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1235050
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-26 22:54:52 CET