Mark. That's a very powerful condemnation of 'clunky' backup practices.
However, you've not gone far enough imo - simply keeping a copy of every (significant?) version of a program isn't taking advantage of modern solutions to the change control problem. As a poster suggested earlier on today, making use of a version control system such as the free and excellent Subversion allows you to keep hundreds of backups of your source code but rather than being a backup of one program, the whole project is snapshotted, each snapshot giving you all your code at that specific point in time. The storage requirements for all of this sounds horrendous but in fact is very modest, as files are stored on an incremental basis. Used properly, subversion can make administering AND developing software a much less stressful task - the basic principle of doing a change on a branch and then only merging it into the trunk when it's ready (and tested!) means changes are isolated from the main body of code until they're complete and changes can be identified, checked, undone etc all after the event. No need to use comments all through your source code to show each little change! Developers on Windows machines have access to TortoiseSVN, also free - it's an explorer shell module that allows subversion administration directly from the windows explorer without having to resort to the command line. Edward -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 11 July 2008 16:42 To: [email protected] Subject: Re: [U2] ouch Louie: Good Technique. I published a similar technique in Spectrum called DCOPY a few years ago. This replaces the pathetic methods that so many undisciplined programmers use where they simply copy the program to the same BP file with a very stupid .BAK or .OLD or other unmanaged suffix. Having the archive in the same file causes FIND or SEARCH programs to constantly include them when not useful. Other similarily pathetic methods are to take the program and, instead of changing the archive name, they change the runtime name to NAME.NEW or NAME.NEW2 etc, etc. This is worse than the suffixed version as trying to FIND the unchanged versions, say NAME, would falsely also find NAME.NEW. This method is also poor as you now must visit all the places NAME is referred from and change to NAME.NEW. I've inherited dozens of systems with these poor techniques. It's very hard and time consuming to systematically determine which programs are on-line and which are the backups. One client had over 15 versions of the same program with varying suffixes. The remaining on-line version was PRINT.ORDERS.NEW3 despite there being a NEW4 and NEW5 version as well. Finally, the backup versions should never be compiled. This prevents an errant programmer from compiling everything. My DCOPY iuncludes a line of text indicating why I made the archive. That line is stored on line 2 of the program (line 1 stays as SUBROUTINE for other analysis) like a comment with no asterisk. Thus, it would not compile at all. My 2 cents, Mark Johnson ----- Original Message ----- From: "Louie Bergsagel" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 09, 2008 3:40 PM Subject: Re: [U2] ouch > A former co-worker of mine had a nifty paragraph he wrote which would edit, > compile, catalog and run a program in one fell swoop. > > Because I detest wasting time with repetitive tasks, I've written a similar > program which also copies the current version of a program to a backup file > in case I trash it, or want to revert to a previous version. > > EDBP [program.name] does the following: > 1. Copies [program.name] to a backup directory (e.g. LOUIEB.BP) with a name > of program.name:"_":date():"_":time():"_".bak" > 2. Executes ED LOUIEB.BP program.name > 3. Executes BASIC and CATALOG commands unless I say no to a prompt. > 4. Executes the cataloged command unless I say no to a prompt. > > This is the poor dude's version control program. > > -- Louie In Seattle > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------------------------------------------------------------------------------------------- Please remember to recycle wherever possible. Reduce, reuse, recycle, think do you need to print this e-mail? ------------------------------------------------------------------------------------------- This e-mail and any attachment(s), is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, dissemination, copying or use of this e-mail or any of its content is prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail, any attachment(s) and any copies. All liability for viruses is excluded to the fullest extent permitted by law. It is your responsibility to scan or otherwise check this email and any attachment(s). Unless otherwise stated (i) views expressed in this message are those of the individual sender (ii) no contract may be construed by this e-mail. Emails may be monitored and you are taken to consent to this monitoring. Civica Services Limited, Company No. 02374268; Civica UK Limited, Company No. 01628868 Both companies are registered in England and Wales and each has its registered office at 2 Burston Road, Putney, London, SW15 6AR. ------------------------------------------------------------------------------------------- ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
