Re: arch 2.0 first source available (git related)

On Sat, 2005-07-09 at 13:39 +0200, Petr Baudis wrote:

Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
where Thomas Lord [off-list ref] told me that...

quoted

2.0 is very much git influenced but it brings some (imo significant)
  improvements to the table.

Could you list some of the things interesting for us? What is the
benefit of a prereq graph compared to just having a single shared object
database? From the documentation, that's the only interesting thing I
noticed which is different from git (and things like artificially
limiting filename length to 256 characters).

Well, partly the statement about improvements was a hint to look
beyond the docs to the code but...

The prereq graph is, indeed, an improvement.  

It:

* speeds up and simplifies blob-db GC

* vastly improves the possibilities for archive integrity
  checking

* can be used for smart, streamy network mirroring of revisions

* allows people to commit the same tree multiple ways: e.g., 
  once optimizing access for users who frequently read incremental
  updates and a second time for users who only update at named
  releases

* helps make the system securable (current code isn't yet) against
  the possibility of multiple files with identical fingerprints but
  different contents in the same or related trees

* helps in a variety of ways when it comes time to make `revc'
  operable over a network -- committing to a remote archive.

Other advantageous (imo) changes from `git' not mentioned in the
original message:

* blobs do not have header lines

  Git blobs all begin with a line of text declaring the "type"
  and size of the blob.   That doesn't increase database 
  verifiability significantly and I found no use for the headers.
  Having the headers makes it needlessly complicated to translate
  a file to or from a blob.

  `revc' does not have blob headers.


* `revc' uses portable file formats

   In working dirs, `git' stores binary files which are 
   endian, word-size, and compiler-environment specific.

   `revc' stores some binary files too (for performance
   and simplicity reasons) but uses only portable formats.

* `revc' is shaping up into much cleaner and more portable code

   (at least compared to the last version of `git' I saw --
    which was extremely *lucid* code but not terribly
    clean and not even attempting to be portable.)

The list goes on and I don't promise to be picking the 
most interesting items from it according to anybody's
particular metric of "interesting".

revc -- probably "strange yet familiar" to git hackers,
-t