From: Petr Baudis Date: Mon, 11 Jul 2005 19:39:44 GMT Subject: Re: arch 2.0 first source available (git related) Message-ID: <20050711193944.GA5981@pasky.ji.cz> In-Reply-To: <1120918813.4901.27.camel@dev1.seyza.com> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter where Thomas Lord 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/ be careful, some twit might quote you out of context..