Re: Control of version

In article <33B6C11E.97A6A8BF@mindspring.com>, Tim Schaefer <tschaefe@mindspring.com> writes >Ian Goddard wrote: >> >> Tim Schaefer wrote: >> <snip> >> > >> > As for file-dependency chaining, this is something that I'd handle >> > in makefiles, but I learn new things every day. :-) >> > >> >> Make handles the fact that one file depends on another but how do you >> make it handle the fact that file2.4gl version 1.4 needs version 1.2 of >> file2.4gl and version 1.3 of file3.per? >> >> Does PVCS do this? In RCS you're simply reduced to putting it in the >> version description. >> >The $(GET) thingy was originally a MAKE built-in to resolve GETting a >file from SCCS, or possibly RCS. I've never really used it, so can't >comment on it other than say, read the man-page or other book(s) on make. >O'reily has a book on it, "Managing Projects with make", ISBN 0-937175-90-0. >I think it can provide you with the answers you need... As always, you'll >have to play around with make to get it to work the way you want. > > >> Defining the version of the database structure is even trickier. You >> could run dbschema after every change and give that a version number - >> but in practice migrating from one version to another might involve some >> ALTER TABLES and even some UPDATES (ALTERing a table to add a non-null >> column isn't a single step process and will involve an UPDATE that >> dbschema can't even capture). Such files must be applied to a specific >> version of the database. >> >> I'm currently working on a site which received updates of a 3rd party >> application every few weeks. I haven't counted the number of source & >> executable files in the system but it runs into thousands! Some of >> these releases involve changes to the database structure. Some of the >> code releases may include changes already installed at the site as >> bug-fixes made in advance of the general code release. This makes me a >> bit sensitive to these issues. The software house concerned seems to >> have nothing like RCS or SCCS in place at all! >> >> Ian > >It is absolutely amazing at how many sites do not have a source code >control implementation, or how many programmers out there that do >not use make. I know of several shops here in Florida with large The current company I am at do not use make, they use a shell script which recompiles ALL modules to each program (up to 17) every time you compile a change. Thats write needlessly compiles 16 modules per build. I wrote a shell sript which creates make files (all modules to a program take the form x111_*.4gl to produce x111.4ge). How did I increase my productivity. Easy, use make and sae several miutes per rebuild. If the change I make to one modules fails I do not have to wait whilst the others get compiled!! I have come to the conclusion that most management do not support their programmers and programmers do not talk to one another. Hence I'll do like the others and do things my way. PS I introduced bzip to send files to customer (better than gzip) we recently got a set of source files down from almost 1M to 80K! Saved ages in phone biils. I'd definately recommend bzip, 30K of C code to send (~6K with compress) and can massively reduce transmission times acroos modems!. >amounts of 4GL, and the programmers do not use make, or SCCS/RCS/PVCS. >Many defer to that sissy i4gl interface, which should be removed >from the system. :-) I know of many who create shell scripts to >compile ESQLC! Make is actually quite easy to use, otherwise I >wouldn't have my digs for these other methods. There is also Microsofts' >nmake for Win95/NT, which is extremely similar to UNIX make, and allows >an additional feature of #if #else #endif programming. > >Jonathan has provided on several occasions his makefile for 4GL, >which should be more than adequate for your needs, and is available >at the iiug archive. I believe it handles ESQL/C as well, although I >haven't used it in a while. You should acquire it and learn from it. > >I challenge you in a most positive way to develop your own make methods. That's my conclusion, if you want it done do it yourself... >If you want additional ideas, I've got make_mk, which produces makefiles >for 4GL, and ESQL/C--to a limited degree--and grnd_mk, which attempts to >produce a makefile for several executables in one makefile, from a flat-file >database of executables. They are at my site, are not perfect, but can >allow you to set up repeatable, consistent makefiles. > Like it! >As I stated before, MAKE is easy to use. You might be surprised at >how little you need in the makefile for a typical 4GL or ESQL/C project. > >Tim -- David Williams