home *** CD-ROM | disk | FTP | other *** search
/ 17 Bit Software 2: Collection B / 17Bit_Collection_B.iso / files / 2254.dms / in.adf / docs / Source.DOC.pp / Source.DOC
Encoding:
Text File  |  1990-09-13  |  6.6 KB  |  142 lines
  1. *******************************************************************************
  2. * SourceUpdate V1.13 - (c) 1991 by Michael Otto. A Utility Factory Production *
  3. *******************************************************************************
  4.  
  5. SourceUpdate is a utility to protocol changes in text-files. SourceUpdate was
  6. especially written to reduce transmission time of source codes via modem.
  7.  
  8. An example: User A writes a program and sends the lastest version of the source
  9. code via modem to user B. User B has already got an older version of the source
  10. code. It would be a waste to send always the WHOLE source code, as many parts
  11. of the code are still similar.
  12.  
  13. As I already mentioned, SourceUpdate is used to detect similarities in the
  14. newer and the older source code and write them to a file. This file and the
  15. older files is used by user B to create the newest version of the source code.
  16. This method implies, though, that user A has ALWAYS got the older AND the newer
  17. version of the source. Keep that in mind, please!
  18.  
  19. SourceUpdate does not use an algorithm that does a byte-to-byte comparison, of
  20. course, because that would lead up to poor "crunching" results. The method is
  21. an algorithm I invented, so few things will be told about it.
  22.  
  23. SourceUpdate is able to handle source codes that consist of more than only one
  24. file. The changes in all files are written to only ONE file (archive), like it
  25. is done by real crunchers, like LHArc.
  26.  
  27. SourceUpdate can usually "crunch" files to about 40-70%, but this ratio depends
  28. -amongst other things- on the similarity of the newer and older files. You may
  29. now think "Oh, 40-70%, that's not much - LHArc does much better in crunching my
  30. files". That's true, but... the archive created by SourceUpdate can and should
  31. be re-crunched by LHArc afterwards (and will definitively bring good results!).
  32. Normally, data transmission length and phone bill can be reduced by 80%.
  33.  
  34. The syntax for updating files is:
  35.  
  36.    SourceUpdate a[a] <archive> <files/patterns> <older version-dir>
  37.                 ^ ^
  38.                 | |
  39.                 +-+- (a=add files)
  40.                   |
  41.                   +- (a=update all files [see below])
  42.  
  43. An example: You (user A) have got the files "main.c" "rarely.c" and "often.c"
  44. in the actual directory. In the directory "Old_Version" there are older
  45. versions of these files - those, which user B has already got.
  46.  
  47. The file "rarely.c" has not been changed in comparison to the "older" version.
  48. The other files have been changed. When you now enter
  49.  
  50.    SourceUpdate a ram:MyUpdate.UPD main.c rarely.c often.c Old_Version
  51.  
  52. then the entered files will be compared to their equivalents in the directory
  53. 'Old_Version' and the changes will be written to "MyUpdate.UPD" (where .UPD
  54. can be left out). Since "rarely.c" has not been changed, it will not be
  55. included in the archive. If the update of the file got longer than the
  56. original file, it would also be left out. You can force SourceUpdate to include
  57. ALL files by entering 'aa' instead of 'a' as the first parameter.
  58.  
  59. The files to be updated can also be specified by wildcards (e.g. SourceUpdate a
  60. ram:MyUpdate.UPD *.c Old_Version). But - ALL FILES TO BE UPDATED HAVE (yet) TO
  61. BE IN THE ACTUAL DIRECTORY! So don't try something like "SourceUpdate a
  62. ram:MyUpdate.UPD /ufc32.lib df1:my_program Old_Version".
  63.  
  64. Do not mix up the 'a' option of SourceUpdate with LHArc's 'a' option, because
  65. SourceUpdate will always create a new UPD-archive file and will not add new
  66. files to an existing archive.
  67.  
  68. Now you should crunch MyUpdate.UPD with LHArc and add those files to the LHArc
  69. archive, which were not included in the SourceUpdate archive because they got
  70. too long. Then transmit the LHArc archive to user B. Afterwards copy all
  71. updated files to your 'Old_Version'-directory (important!).
  72.  
  73. Now user B has to unpack the LHArc archive and copy all files except for the
  74. SourceUpdate archive e.g. to the ram: disk. Now user B is to enter (generally)
  75.  
  76.    SourceUpdate x <archive> <older version-dir> <destination-dir>
  77.  
  78. or more concretely:
  79.  
  80.    SourceUpdate x MyUpdate.UPD <source-dir [old version]> ram:
  81.  
  82. Now all updated files are unpacked and copied to ram. The ram: disk should now
  83. be copied to the user's actual source directory, which then holds the latest
  84. version of the source code of user A. User B HAS TO make a copy of this
  85. directory, because ««« NO "old version" FILES MUST BE CHANGED »»», since
  86. SourceUpdate needs the same old files for packing as for unpacking!
  87.  
  88. If you keep all these things in mind, then source code transmission will
  89. become much faster and cheaper!
  90.  
  91. The algorithm used by SourceUpdate works best with text files, though
  92. executables may be updated either - but with worse results. Sorry, but that is
  93. caused by their relocability.
  94.  
  95. Of course there's no need to update only source codes. You may update
  96. documentation files, etc. etc. or use SourceUpdate for updating parts of
  97. harddisk-backups.
  98.  
  99. *******************************************************************************
  100.  
  101. Use this program at your own risk. I will especially not take any
  102. responsibility for mutilated source codes. No trust?
  103.  
  104. SourceUpdate is FREEWARE, i.e. the copyright is reserved. But you may copy
  105. SourceUpdate to anyone you like. SourceUpdate must not be distributed in PD
  106. series without my permission. This permission will not be given to persons or
  107. firms who take more than DM 4 (US $3) for any of their PD disks.
  108.  
  109. Send bug reports, hints, grown up sisters, creditcards, blue boxes, teddybears,
  110. hispeed modems, mitropa duschhauben/kaffeemaschinen or any other tokens to
  111.  
  112.    Michael Otto, Holländische Twiete 6a, 2054 Geesthacht, Germoney
  113.    or to MICHAEL_OTTO@ANM.ZER
  114.  
  115. *********************************** HISTORY ***********************************
  116.  
  117. V1.03: - crunching algorithm optimized
  118.        - does better crunching of executables now
  119.        - files that got just some bytes longer than the original are now
  120.          included in the archive, because LHArc also needs some extra bytes
  121.          for every archive entry
  122.  
  123. V1.1:  - crunching speed increased by factor upto 4
  124.          (executables slower, though)
  125.        - further improved crunching algorithm
  126.          does better with files that changed only little
  127.  
  128. V1.12: - crunching algorithm bug fixed
  129.        - crunching algorithm improved:
  130.          does now generally better and crunches files to about 1/3 of V1.00
  131.  
  132. V1.13: - crunching algorithm bug fixed
  133.          (sourceupdates history seems to be a history of endless bux fixes
  134.           and algorithm improvements...)
  135.  
  136. ************************************* END *************************************
  137.  
  138. Post Scriptum: Special thanks to Daniel Hanisch for being "user B".
  139.  
  140. ********************************** REAL END ***********************************
  141.  
  142.