![]() |
|
|
google unix.com
|
|||||||
| Forums | Register | Forum Rules | Links | Albums | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| Shell Programming and Scripting Post questions about KSH, CSH, SH, BASH, PERL, PHP, SED, AWK and OTHER shell scripts and shell scripting languages here. |
More UNIX and Linux Forum Topics You Might Find Helpful
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| A handful of desktop utilities for snipping multiple clips | iBot | UNIX and Linux RSS News | 0 | 01-04-2008 05:40 AM |
| Manage starting point in shell script. | ai_dba | Shell Programming and Scripting | 6 | 08-29-2007 06:08 AM |
| Trying to manage an inherited Ksh script | ajcannon | Shell Programming and Scripting | 1 | 08-15-2007 07:54 AM |
| Using multiple java versions in unix | umen | UNIX for Dummies Questions & Answers | 2 | 09-05-2005 11:44 AM |
| top ten utilities in shell scripting? | diego | UNIX for Dummies Questions & Answers | 3 | 08-03-2005 12:00 AM |
![]() |
|
|
LinkBack | Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
||||
|
Hi all ---
I have the need to manage multiple versions of a set of utility scripts -- both shell and SQL and other .dat files. I am wondering if anyone out there knows of a good way to "PATH" to SQL and text files in a way similar to how PATH facilitates finding executables in a pre-specified order. For instance, I have 4 directories (versions) of my utilities -- New, Current, Old, Older. In Older I have a complete set of my utilities; under Old I have those files that were changed since Older; in Current I have those files that were changed since either Old or Older. In New I have only those files that are still being tested and which have been changed since either Current, Old or Older. Using PATH I can specify how to find my executables (shell scripts): For Production -- PATH=/Current:/Old:/Older: For Test -- PATH=/New:/Current:/Old:/Older: But this won't help for non-executables like SQL (text). How do I dynamically find the text files? Thanks much in advance! |
|
||||
|
Perhaps you could have your scripts locate your text files relative to $0 ; that is, relative to the running script's location. You can use the `dirname' command to remove the filename from $0 leaving you with its parent directory.
|
|
||||
|
Dennis, there is no easy answer to Source Control and Configuration Management.
Using a Source Control utility such as SCCS, RCS, CVS or (for Windows) Source Safe is an integral activity for project development. I recommend you start using a Source Control utility if you do not already do so. Your Configuration Management method may seem logical for the time being, but could become tricky to manage with a large amount of files. Your method, from a systems testing point of view, has a flaw - you do not have a single definitive version of your system to test against. As well as other problems, it means (I think) that you and the testers are both working in the same system? Consider using something like this: DEVELOPMENT->TEST->LIVE where each environment would contain complete suite of your files at whichever version level applies. You would then have an enviromental variable referencing the base directory to the environment e.g. SYSDIR=/software/dev or SYSDIR=/software/test The system files would then be referenced in relation to that directory e.g. $SYSDIR/Bin/myexe $SYSDIR/Scripts/myscript.sql $SYSDIR/Sql/mysql.sql Anyway this is just a suggestion, take it or leave it as you wish. Also, how do you track changes to your database? It is not clear if you are controlling changes to it or not? Remember a database is in effect a global data area. Because of this, be extremely cautious of making changes to it, especially when you have gone live with your system. On the subject of Source Control and Configuration Management I urge you to take the following steps: 1) Document your method of version control and how to 'release' a version of a file. Just so everyone knows what is supposed to happen and when ... 2) Document all files, and at which versions, when you make a 'release'. 3) Document a backout plan for a 'release'. 4) Take regular backups of everything. Test the backups will actually work too!. Hope this helps MBB |
![]() |
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|