[raptor - Sun at 04:37:54PM +0200]
> so U set those variables in config file /sites/config/Config.pm and this
> file is under CVS control, what is the problem here. Both Config.pm must be
> different ('cause they represent different file structures), but U still
> want when u add new Variable in the DEV-Config.pm it to be updated on the
> Production-Config.pm, on the other hand U want to preserve the values that u
> have on Production server, but not edit them by hand every time u make
> Update on the Production server.I've been in similar situations myself - having a Config.pm that contained a lot of common information, but some few truely local variables. I've tried dealing with it in different ways. I'll first comment your options, then add some more. > So what u do in those cases !? > > 1. Copy temporarily this file off-site, make "cvs update", return it back > (overwrite dev-version), manualy edit it if some new stuff are added You can do it easier, just edit your local changes into the file, never commit it, and forget about it. When you do a "cvs update", no local changes will be undone. Changes in the repository will be merged into the local file. Of course, there might be conflicts, that's the only bad thing. In the repository, you should have a generic file; don't fill in any local information, leave everything either blank or with sane default values, or with weird example values. This solution will probably be the best if you're not afraid of conflicts, if the file is not updated too frequently in the repository, and you don't need to have version control on local configurations. It will probably break a bit with my previous suggestion about never editing things directly at your PrimaryDevServer, but always update them through the CVS. > 2. make a Selective update dir by dir (not the whole repository at once, so > that this config file is not touched) Sounds like a nightmare. I'd propose an alternative; have all configurations in a separate directory, and use a different (local!) $CVSROOT for the configurations. I haven't tried this myself, but I'd daresay it's perfectly possible. This is the best option if you want to have version control on local configurations, and don't need/want to share it with others. The local configuration directory, filled in with default values, should probably be placed there in the first place by some installation suite (Makefile, typically). The default values should probably be stored in the central repository. I.e. have a configuration directory called "Default", and another called "PrimaryDevServer", and have some logic in the script choosing the right configuration file. This might be the best option if the software is to be distributed widly, and you want to attach default configuration, maybe some example configurations, and some local configurations as well in the main CVS, but also give people possibility to have their configuration in local CVS repositories. This solution is not so good if you make a lot of changes in the configuration file setup that needs to be copied into each of the subdirectories. > 3. Remove this file from CVS control and copy it manualy when needed (very > ugly u may loose usefull info) That is another option. It doesn't need to be so ugly, because you should probably make an installation kit where a Makefile will create those local files for the user (as mentioned in #2). This is the best option if you want to make some software that is to be distributed widly, and neither you nor the other users will need CVS control on their local configuration. So ... some more alternatives: 4. Make a template file, and a Makefile that creates the configuration file. In a perl script, the first line (typically #!/usr/bin/perl) should also be replaced by the Makefile. We did have such a solution, with all configurative variables in the Makefile, and duplicated in some Config.pm-file. For me, this solution was horrible. For one thing, the configuration trouble was just moved, the Makefile would need to be edited instead of the Config.pm-file. When debugging and developing the script as well as the config-file, I'd like to work directly with the script, not on the templates. This solution was both inefficient and cumbersome for me, though it could probably be solved through some clever scripting. 5. Make separate branches for each local configuration. I've tried that too. I don't remember why, but this solution did cause some frustration for me. I think my problem was that I branched the whole project, not only the configuration file. This is probably the best thing to do if you want all the local configurations to be in the same CVS repository. This solution is also perfectly compatible with my earlier suggestion about never editing files at the PrimaryDevServer, but always update it through CVS. The local branch of the configuration can be checked out in a separate directory at any of the work stations, edited, committed, and then automaticly updated at PrimaryDevServer. To handle branching, you will need to read quite a bit in the CVS documentation, and you will need to keep your head straight - it's probably worth it anyway, if you're to use CVS a lot, you'll need to handle branching sooner or later. 6. Now I'll try to describe what I did for my project ... it's a bit perl specific, and it certainly became a bit complex. I think it's the best way to do it if the configuration is quite complex, lots of configuration variables depends more or less on each other, and most of the default values can be used at any site, but some few things needs to be overridden. I made a very short script - like five-six lines - telling where the perl executable was located, where the libraries were located and what configuration file to pull in. The script itself would then pull in one library and the configuration, and start the "main"-sub. I made a template for this script, the script itself was generated through a Makefile. I guess ExtUtils::MakeMaker can be used for dealing with the Makefile and those few configurations. So, what configuration file to use (and what directory to find it in) is written in one tiny file that probably never will need any serious updating. It's freely up to the local administrator whether he wants his local configuration within the main repository, or in a separate directory which he eventually have local version control on. I made the configuration itself semi-object-oriented, so I had a "configuration object" that was instanciated in the abovementionated script. The very most of the configuration was global variables, some few things was defined as methods under the configuration object. The latter must be the most Right way to do it in an object oriented world - but, I think I discovered it was easier to use global variables after all. The variables was, by default, initiated through methods. So, I would have a method InitiateConfig, which called other methods - like InitiateLogging, InitiateDirectoryStructure, etc. The local configuration file would inheritate the global configuration file directly or indirectly, consist only of some few lines overriding the necessary variables _or_ initilization methods either directly or indirectly. Some small example file would be provided in the central CVS repository, and local managers (with permission to write to the repository) would be able to add their configuration on their own liking. Since the local configuration file can be in the repository, the solution is perfectly compatible with my suggestion about updating PrimaryDevServer only through the CVS. -- Unemployed hacker Will program for food! http://ccs.custompublish.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
