{"thread":{"id":"1179","subject":"arch 2.0 first source available (git related)","startedAt":"2005-07-09T00:12:27Z","lastAt":"2005-07-12T00:05:57Z","messageCount":7,"participants":["Thomas Lord","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5840","messageId":"1120867947.5882.2.camel@dev1.seyza.com","threadId":"1179","inReplyTo":null,"subject":"arch 2.0 first source available (git related)","fromName":"Thomas Lord","fromEmail":"lord@emf.net","sentAt":"2005-07-09T00:12:27Z","receivedAt":"2005-07-09T00:12:27Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"\nThe first source release and some very early documentation for Arch 2.0\n(\"revc\") is now ready!\n\n Web page: \n\n Source: \n\n Source (tar bundle) SHA1:\n\t\t9c279f78e57a99d517ccf5b983960620ff6f2cf7\n\n Source (tar bundle) size: 1732018\n\nSome highlights: revc has only 10 core commands; there are about 165\nfunctions; the source code is literally about 14K lines and is closer to\n10K lines if you subtract out non-code boilerplate.\n\nUser complaints about tla 1.x being addressed in revc:\n\ninventory is too complicated -- but is drastically simplified (almost\n eliminated) in 2.0\n\nwe hate the funny filenames -- 2.0 requires only a single .revc\n directory and you aren't expected to edit any files there. No more\n {arch}, {arch}/=tagging-method, or deeply nested project-tree logs\n\nthe namespace blows -- 2.0 allows just about any revision name that\n doesn't contain a slash character. There is a moderate limit on the\n length of a revision name.\n\nall this stuff about registering archives and making mirrors is hard to\nlearn -- and, in 2.0, it's all gone. You can use rsync to mirror stuff,\n for starters. And all archives are anonymous -- there's no longer any\n such thing as an archive name.\n\ntoo much is too slow -- although the 2.0 code isn't especially optimized\n yet, it seems to be hella snappy.\n\n2.0 is very much git influenced but it brings some (imo significant)\n improvements to the table.\n\n-t\n"},{"id":"5863","messageId":"20050709113942.GB26343@pasky.ji.cz","threadId":"1179","inReplyTo":"1120867947.5882.2.camel@dev1.seyza.com","subject":"Re: arch 2.0 first source available (git related)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-09T11:39:43Z","receivedAt":"2005-07-09T11:39:43Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter\nwhere Thomas Lord told me that...\n> 2.0 is very much git influenced but it brings some (imo significant)\n> improvements to the table.\n\nCould you list some of the things interesting for us? What is the\nbenefit of a prereq graph compared to just having a single shared object\ndatabase? From the documentation, that's the only interesting thing I\nnoticed which is different from git (and things like artificially\nlimiting filename length to 256 characters).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5867","messageId":"1120918813.4901.27.camel@dev1.seyza.com","threadId":"1179","inReplyTo":"20050709113942.GB26343@pasky.ji.cz","subject":"Re: arch 2.0 first source available (git related)","fromName":"Thomas Lord","fromEmail":"lord@emf.net","sentAt":"2005-07-09T14:20:13Z","receivedAt":"2005-07-09T14:20:13Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"On Sat, 2005-07-09 at 13:39 +0200, Petr Baudis wrote:\n> Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter\n> where Thomas Lord told me that...\n> > 2.0 is very much git influenced but it brings some (imo significant)\n> > improvements to the table.\n> \n> Could you list some of the things interesting for us? What is the\n> benefit of a prereq graph compared to just having a single shared object\n> database? From the documentation, that's the only interesting thing I\n> noticed which is different from git (and things like artificially\n> limiting filename length to 256 characters).\n\nWell, partly the statement about improvements was a hint to look\nbeyond the docs to the code but...\n\nThe prereq graph is, indeed, an improvement. \n\nIt:\n\n* speeds up and simplifies blob-db GC\n\n* vastly improves the possibilities for archive integrity\n checking\n\n* can be used for smart, streamy network mirroring of revisions\n\n* allows people to commit the same tree multiple ways: e.g., \n once optimizing access for users who frequently read incremental\n updates and a second time for users who only update at named\n releases\n\n* helps make the system securable (current code isn't yet) against\n the possibility of multiple files with identical fingerprints but\n different contents in the same or related trees\n\n* helps in a variety of ways when it comes time to make `revc'\n operable over a network -- committing to a remote archive.\n\nOther advantageous (imo) changes from `git' not mentioned in the\noriginal message:\n\n* blobs do not have header lines\n\n Git blobs all begin with a line of text declaring the \"type\"\n and size of the blob. That doesn't increase database \n verifiability significantly and I found no use for the headers.\n Having the headers makes it needlessly complicated to translate\n a file to or from a blob.\n\n `revc' does not have blob headers.\n\n\n* `revc' uses portable file formats\n\n In working dirs, `git' stores binary files which are \n endian, word-size, and compiler-environment specific.\n\n `revc' stores some binary files too (for performance\n and simplicity reasons) but uses only portable formats.\n\n* `revc' is shaping up into much cleaner and more portable code\n\n (at least compared to the last version of `git' I saw --\n which was extremely *lucid* code but not terribly\n clean and not even attempting to be portable.)\n\nThe list goes on and I don't promise to be picking the \nmost interesting items from it according to anybody's\nparticular metric of \"interesting\".\n\nrevc -- probably \"strange yet familiar\" to git hackers,\n-t\n"},{"id":"5960","messageId":"20050711193944.GA5981@pasky.ji.cz","threadId":"1179","inReplyTo":"1120918813.4901.27.camel@dev1.seyza.com","subject":"Re: arch 2.0 first source available (git related)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-11T19:39:44Z","receivedAt":"2005-07-11T19:39:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter\nwhere Thomas Lord told me that...\n> The prereq graph is, indeed, an improvement. \n..snip..\n\nBut object retrieval can be potentially as much as linear to the depth\nof the prereq graph, right? I don't think any of the benefits you listed\nare worth the complication, and you can still do the reachability\nanalysis pretty easily. (And I think it takes the same number of\nroundtrips when downloading from remote server?)\n\n> Other advantageous (imo) changes from `git' not mentioned in the\n> original message:\n> \n> * blobs do not have header lines\n> \n> Git blobs all begin with a line of text declaring the \"type\"\n> and size of the blob. That doesn't increase database \n> verifiability significantly and I found no use for the headers.\n> Having the headers makes it needlessly complicated to translate\n> a file to or from a blob.\n> \n> `revc' does not have blob headers.\n\nIn git, this is crucial at least for distinguishing commits and tags.\nI personally consider the verifiability boost useful.\n\n> * `revc' uses portable file formats\n> \n> In working dirs, `git' stores binary files which are \n> endian, word-size, and compiler-environment specific.\n> \n> `revc' stores some binary files too (for performance\n> and simplicity reasons) but uses only portable formats.\n\nI think they are only word-size specific, and that should be no big\nmatter to resolve, shall anyone want to.\n\n> * `revc' is shaping up into much cleaner and more portable code\n> \n> (at least compared to the last version of `git' I saw --\n> which was extremely *lucid* code but not terribly\n> clean and not even attempting to be portable.)\n\nAll right, the portability could be better. ;-)\n\nKind regards,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5967","messageId":"1121117816.16511.5.camel@dev1.seyza.com","threadId":"1179","inReplyTo":"20050711193944.GA5981@pasky.ji.cz","subject":"Re: arch 2.0 first source available (git related)","fromName":"Thomas Lord","fromEmail":"lord@emf.net","sentAt":"2005-07-11T21:36:56Z","receivedAt":"2005-07-11T21:36:56Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:\n> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter\n> where Thomas Lord told me that...\n> > The prereq graph is, indeed, an improvement. \n> ..snip..\n\n> But object retrieval can be potentially as much as linear to the depth\n> of the prereq graph, right? \n\nPotentially but not, by far, in the common case.\n\nMoreover, that depth is an arbitrary parameter which user's can\nfreely vary -- that's part of the point.\n\n\n> I don't think any of the benefits you listed\n> are worth the complication, and you can still do the reachability\n> analysis pretty easily. (And I think it takes the same number of\n> roundtrips when downloading from remote server?)\n> \n\nI don't agree that any complication is added. I know that \nsome complications are avoided with this approach.\n\n-t\n"},{"id":"5978","messageId":"20050711233150.GB5981@pasky.ji.cz","threadId":"1179","inReplyTo":"1121117816.16511.5.camel@dev1.seyza.com","subject":"Re: arch 2.0 first source available (git related)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-11T23:31:50Z","receivedAt":"2005-07-11T23:31:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter\nwhere Thomas Lord told me that...\n> On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:\n> > Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter\n> > where Thomas Lord told me that...\n> > > The prereq graph is, indeed, an improvement. \n> > ..snip..\n> \n> > But object retrieval can be potentially as much as linear to the depth\n> > of the prereq graph, right? \n> \n> Potentially but not, by far, in the common case.\n> \n> Moreover, that depth is an arbitrary parameter which user's can\n> freely vary -- that's part of the point.\n\nBut if the depth will be less than that, won't the user end up with some\n(plenty) of the objects duplicated?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5987","messageId":"1121126757.24076.2.camel@dev1.seyza.com","threadId":"1179","inReplyTo":"20050711233150.GB5981@pasky.ji.cz","subject":"Re: arch 2.0 first source available (git related)","fromName":"Thomas Lord","fromEmail":"lord@emf.net","sentAt":"2005-07-12T00:05:57Z","receivedAt":"2005-07-12T00:05:57Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"On Tue, 2005-07-12 at 01:31 +0200, Petr Baudis wrote:\n\n> But if the depth will be less than that, won't the user end up with some\n> (plenty) of the objects duplicated?\n\n\nSome, yes, many, no. It's pretty easy to tune how many, afaict.\n\n-t\n"}]}