******************************************************************************* * SourceUpdate V1.13 - (c) 1991 by Michael Otto. A Utility Factory Production * ******************************************************************************* SourceUpdate is a utility to protocol changes in text-files. SourceUpdate was especially written to reduce transmission time of source codes via modem. An example: User A writes a program and sends the lastest version of the source code via modem to user B. User B has already got an older version of the source code. It would be a waste to send always the WHOLE source code, as many parts of the code are still similar. As I already mentioned, SourceUpdate is used to detect similarities in the newer and the older source code and write them to a file. This file and the older files is used by user B to create the newest version of the source code. This method implies, though, that user A has ALWAYS got the older AND the newer version of the source. Keep that in mind, please! SourceUpdate does not use an algorithm that does a byte-to-byte comparison, of course, because that would lead up to poor "crunching" results. The method is an algorithm I invented, so few things will be told about it. SourceUpdate is able to handle source codes that consist of more than only one file. The changes in all files are written to only ONE file (archive), like it is done by real crunchers, like LHArc. SourceUpdate can usually "crunch" files to about 40-70%, but this ratio depends -amongst other things- on the similarity of the newer and older files. You may now think "Oh, 40-70%, that's not much - LHArc does much better in crunching my files". That's true, but... the archive created by SourceUpdate can and should be re-crunched by LHArc afterwards (and will definitively bring good results!). Normally, data transmission length and phone bill can be reduced by 80%. The syntax for updating files is: SourceUpdate a[a] ^ ^ | | +-+- (a=add files) | +- (a=update all files [see below]) An example: You (user A) have got the files "main.c" "rarely.c" and "often.c" in the actual directory. In the directory "Old_Version" there are older versions of these files - those, which user B has already got. The file "rarely.c" has not been changed in comparison to the "older" version. The other files have been changed. When you now enter SourceUpdate a ram:MyUpdate.UPD main.c rarely.c often.c Old_Version then the entered files will be compared to their equivalents in the directory 'Old_Version' and the changes will be written to "MyUpdate.UPD" (where .UPD can be left out). Since "rarely.c" has not been changed, it will not be included in the archive. If the update of the file got longer than the original file, it would also be left out. You can force SourceUpdate to include ALL files by entering 'aa' instead of 'a' as the first parameter. The files to be updated can also be specified by wildcards (e.g. SourceUpdate a ram:MyUpdate.UPD *.c Old_Version). But - ALL FILES TO BE UPDATED HAVE (yet) TO BE IN THE ACTUAL DIRECTORY! So don't try something like "SourceUpdate a ram:MyUpdate.UPD /ufc32.lib df1:my_program Old_Version". Do not mix up the 'a' option of SourceUpdate with LHArc's 'a' option, because SourceUpdate will always create a new UPD-archive file and will not add new files to an existing archive. Now you should crunch MyUpdate.UPD with LHArc and add those files to the LHArc archive, which were not included in the SourceUpdate archive because they got too long. Then transmit the LHArc archive to user B. Afterwards copy all updated files to your 'Old_Version'-directory (important!). Now user B has to unpack the LHArc archive and copy all files except for the SourceUpdate archive e.g. to the ram: disk. Now user B is to enter (generally) SourceUpdate x or more concretely: SourceUpdate x MyUpdate.UPD ram: Now all updated files are unpacked and copied to ram. The ram: disk should now be copied to the user's actual source directory, which then holds the latest version of the source code of user A. User B HAS TO make a copy of this directory, because ««« NO "old version" FILES MUST BE CHANGED »»», since SourceUpdate needs the same old files for packing as for unpacking! If you keep all these things in mind, then source code transmission will become much faster and cheaper! The algorithm used by SourceUpdate works best with text files, though executables may be updated either - but with worse results. Sorry, but that is caused by their relocability. Of course there's no need to update only source codes. You may update documentation files, etc. etc. or use SourceUpdate for updating parts of harddisk-backups. ******************************************************************************* Use this program at your own risk. I will especially not take any responsibility for mutilated source codes. No trust? SourceUpdate is FREEWARE, i.e. the copyright is reserved. But you may copy SourceUpdate to anyone you like. SourceUpdate must not be distributed in PD series without my permission. This permission will not be given to persons or firms who take more than DM 4 (US $3) for any of their PD disks. Send bug reports, hints, grown up sisters, creditcards, blue boxes, teddybears, hispeed modems, mitropa duschhauben/kaffeemaschinen or any other tokens to Michael Otto, Holländische Twiete 6a, 2054 Geesthacht, Germoney or to MICHAEL_OTTO@ANM.ZER *********************************** HISTORY *********************************** V1.03: - crunching algorithm optimized - does better crunching of executables now - files that got just some bytes longer than the original are now included in the archive, because LHArc also needs some extra bytes for every archive entry V1.1: - crunching speed increased by factor upto 4 (executables slower, though) - further improved crunching algorithm does better with files that changed only little V1.12: - crunching algorithm bug fixed - crunching algorithm improved: does now generally better and crunches files to about 1/3 of V1.00 V1.13: - crunching algorithm bug fixed (sourceupdates history seems to be a history of endless bux fixes and algorithm improvements...) ************************************* END ************************************* Post Scriptum: Special thanks to Daniel Hanisch for being "user B". ********************************** REAL END ***********************************