{"thread":{"id":"628","subject":"Re: Mercurial 0.4e vs git network pull","startedAt":"2005-05-15T11:52:50Z","lastAt":"2005-05-15T14:23:08Z","messageCount":2,"participants":["Adam J. Richter","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3355","messageId":"200505151152.j4FBqoW01239@adam.yggdrasil.com","threadId":"628","inReplyTo":null,"subject":"Re: Mercurial 0.4e vs git network pull","fromName":"Adam J. Richter","fromEmail":"adam@yggdrasil.com","sentAt":"2005-05-15T11:52:50Z","receivedAt":"2005-05-15T11:52:50Z","isPatch":false,"sender":{"key":"adam@yggdrasil.com","avatar":null},"body":"On Sun, 15 May 2005 14:40:42 +0200, Petr Baudis wrote:\n>Dear diary, on Sun, May 15, 2005 at 01:22:19PM CEST, I got a letter\n>where \"Adam J. Richter\" told me that...\n[...]\n>> \tI don't understand what was wrong with Jeff Garzik's previous\n>> suggestion of using http/1.1 pipelining to coalesce the round trips.\n>> If you're worried about queuing too many http/1.1 requests, the client\n>> could adopt a policy of not having more than a certain number of\n>> requests outstanding or perhaps even making a new http connection\n>> after a certain number of requests to avoid starving other clients\n>> when the number of clients doing one of these transfers exceeds the\n>> number of threads that the http server uses.\n\n>The problem is that to fetch a revision tree, you have to\n\n>\tsend request for commit A\n>\treceive commit A\n>\tlook at commit A for list of its parents\n>\tsend request for the parents\n>\treceive the parents\n>\tlook inside for list of its parents\n>\t...\n\n>(and same for the trees).\n\n\tDon't you usually have a list of many files for which you\nwant to retrieve this information? I'd imagine that would usually\nsuffice to fill the pipeline.\n\n __ ______________\nAdam J. Richter \\ /\nadam@yggdrasil.com | g g d r a s i l\n"},{"id":"3357","messageId":"20050515142307.GF13024@pasky.ji.cz","threadId":"628","inReplyTo":"200505151152.j4FBqoW01239@adam.yggdrasil.com","subject":"Re: Mercurial 0.4e vs git network pull","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-15T14:23:08Z","receivedAt":"2005-05-15T14:23:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, May 15, 2005 at 01:52:50PM CEST, I got a letter\nwhere \"Adam J. Richter\" told me that...\n> On Sun, 15 May 2005 14:40:42 +0200, Petr Baudis wrote:\n> >Dear diary, on Sun, May 15, 2005 at 01:22:19PM CEST, I got a letter\n> >where \"Adam J. Richter\" told me that...\n> [...]\n> >> \tI don't understand what was wrong with Jeff Garzik's previous\n> >> suggestion of using http/1.1 pipelining to coalesce the round trips.\n> >> If you're worried about queuing too many http/1.1 requests, the client\n> >> could adopt a policy of not having more than a certain number of\n> >> requests outstanding or perhaps even making a new http connection\n> >> after a certain number of requests to avoid starving other clients\n> >> when the number of clients doing one of these transfers exceeds the\n> >> number of threads that the http server uses.\n> \n> >The problem is that to fetch a revision tree, you have to\n> \n> >\tsend request for commit A\n> >\treceive commit A\n> >\tlook at commit A for list of its parents\n> >\tsend request for the parents\n> >\treceive the parents\n> >\tlook inside for list of its parents\n> >\t...\n> \n> >(and same for the trees).\n> \n> \tDon't you usually have a list of many files for which you\n> want to retrieve this information? I'd imagine that would usually\n> suffice to fill the pipeline.\n\nThat might be true for the trees, but not for the commit lists. Most\ncommits have a single parent, except merges, which are however extremely\nrare with more than two parents too.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"}]}