Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord <[EMAIL PROTECTED]> told me that...
> The prereq graph is, indeed, an improvement.  
..snip..

But object retrieval can be potentially as much as linear to the depth
of the prereq graph, right? I don't think any of the benefits you listed
are worth the complication, and you can still do the reachability
analysis pretty easily. (And I think it takes the same number of
roundtrips when downloading from remote server?)

> 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.

In git, this is crucial at least for distinguishing commits and tags.
I personally consider the verifiability boost useful.

> * `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.

I think they are only word-size specific, and that should be no big
matter to resolve, shall anyone want to.

> * `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.)

All right, the portability could be better. ;-)

Kind regards,

-- 
                                Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to