Re: arch 2.0 first source available (git related)

From: Thomas Lord <lord@emf.net>
Date: Jul 9, 2005, 14:20 UTC
Message-ID: <1120918813.4901.27.camel@dev1.seyza.com>
In-Reply-To: <20050709113942.GB26343@pasky.ji.cz>

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

Show 10 quoted lines

> Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > 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