At the moment I just use another boss.config file for production, named 
boss.config.rel - my build script copies it over development one into the 
build directory from which .deb, .rpm and .tar.gz packages are generated by 
the same script. 

It would be nice to have something like boss.config and boss.config.dev - 
.dev should be loaded automatically with init-dev.sh (or load boss.config 
if boss.config.dev does not exist), init.sh should load boss.config. Having 
just one file with ifs' would be impractical when the app is getting 
packaged into a package such as .deb - in this case boss.config file is 
usually marked as 'config file', this prevents blind overwriting of it by a 
package manager in case when user did any modifications to the old config 
file. When developer makes changes to this file (and developers do this 
often), even in developer 'if' branch, package manager sees this file as 
modified  (a new branch of this file) and will show an unnecessary prompt 
to the user - what to do with the changed config file. Imo having two 
separate config files would be fine and easier to implement.

пятница, 30 мая 2014 г., 15:09:14 UTC+4 пользователь David Welton написал:
>
> I asked this on the Erlang list: 
>
> http://erlang.org/pipermail/erlang-questions/2014-May/079310.html 
>
> The ideal thing would really be to have a common config file, with 
> perhaps some kind of if/else for small differences.  Or auxiliary 
> files for dev and production that contain additional configuration for 
> those. 
>
> Thoughts? 
> -- 
> David N. Welton 
>
> http://www.welton.it/davidw/ 
>
> http://www.dedasys.com/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/chicagoboss/e47b2e94-d39b-4180-a441-544d591185ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to