We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area.
For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files.
Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible.
So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time.
John-
On Wed, 30 Oct 2002 21:09:05 +0000
Richard Clarke <[EMAIL PROTECTED]> wrote:
Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website?
Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar.
I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption?
Does anyone have any recommended method? I don't use version numbers at all? Does anyone?
Richard.
