I now have system-type application-admin support of some applications and to control what goes on I'm having the app-admin folks place all company-written scripts and data files (data files that drive the app, not data files as in temporary or database files) into cvs. What I have at for the current app is:
/app /bin /prod /lookups /scripts /ftp /test /lookups /scripts /ftp /dev /lookups /scripts /ftp I'm thinking of having the cvs repo so that it looks like: /app /bin /lookups /scripts /ftp and making the changes as necessary at 'cvs co' time. On the next version of the app I will have the admin people install the app in all three environments so that it mirrors the cvs repo exactly. To reduce the activity in production and to reduce what the app developers can do I'm going to change all app common account passwords and create each app developer an individual account, teaching them how to deal with cvs. I have also created a samba share to their home directories so they can edit the files as if the files were coming from a windows native share instead of having to ftp the files to their workstations, edit the files, then ftp the files back (their editor does the ftp part for them). To make things easier for the developers I'm writing a script that will run in their home directories looking for those directories that have a 'CVS' directory. When that directory is found then the script does a 'cvs -n update' looking for files that have been modified, files in cvs that are not local, and files that are local but not in cvs. Using the three types of files the script looks for a file named 'cvs.files'. In that file if the modified file is listed at the beginning of the line, the file is then 'cvs ci -m "MESSAGE" FILE' with the rest of the line. If the file is local, and not yet in cvs, and is at the first of the line, then the script will do a 'cvs add FILE' followed by a checkin. I've not yet thought of a good way to setup a pull from the repo, and a remove from the repo. Does this make sense? I feel like I'm just blathering on. Also, if anyone has some ideas or things I've not thought about I'd appreciate hearing them. Files beginning with blank or '#' are ignored. 'datafile' will be checked in as: cvs ci -m 'added partner foobar' datafile. 'datafile.sh' will not be checked. The line #+datafile.pl... how about this to indicate the file exists in cvs, but not locally. Then removing the '#' would say to the script to do a 'cvs co datafile.pl'? What about some directive to update the local versions with the versions from cvs (for unit testing prior to checkin)? ------------------------------------ cvs.file # last processed: Thu Nov 25 10:28:21 CST 2004 # 0 files checked in, 0 files added, 0 files removed # directory: txedi001:/home/user/app/lookups # cvsroot: :pserver:[EMAIL PROTECTED]:/opt/CVS/cvsroot # # files: datafile added partner foobar #datafile.sh #+datafile.pl # end of cvs.files ------------------------------------ cvs.file Also this is for an application that is made of three environments. What I'm considering is first checkin PROD, then add a '-t PROD' tag to the last version. Then checking TEST adding a '-t TEST' to that last version. I don't want the developers to know how to add tags, either that or not let them add/change tags. In production I intend to for the weekly rollout of code do a 'cvs co -t PROD app'. How to prevent the developers from adding tags? Is this a good way to manage the three environments? Mike _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs