{"thread":{"id":"2772","subject":"server-info dumbing-down","startedAt":"2005-12-07T21:58:53Z","lastAt":"2005-12-07T22:45:58Z","messageCount":2,"participants":["Petr Baudis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13336","messageId":"20051207215853.GL22159@pasky.or.cz","threadId":"2772","inReplyTo":null,"subject":"server-info dumbing-down","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-07T21:58:53Z","receivedAt":"2005-12-07T21:58:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hello,\n\n  I've noticed few commits from Dec 4 landing into the git repository,\nwhich remove various computations and corresponding lines from the\nserver info (3e15c67 and few ancestors). I'm curious about this - were\nthe computations that hugely computationally expensive? If not, wouldn't\nit be better to leave it in for future use (since it doesn't cost a lot)\nrather than making the future deployment of anything using this data\nmuch harder since the server infos won't have it anymore?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13340","messageId":"7vzmncmspl.fsf@assigned-by-dhcp.cox.net","threadId":"2772","inReplyTo":"20051207215853.GL22159@pasky.or.cz","subject":"Re: server-info dumbing-down","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T22:45:58Z","receivedAt":"2005-12-07T22:45:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n>   I've noticed few commits from Dec 4 landing into the git repository,\n> which remove various computations and corresponding lines from the\n> server info (3e15c67 and few ancestors). I'm curious about this - were\n> the computations that hugely computationally expensive? If not, wouldn't\n> it be better to leave it in for future use (since it doesn't cost a lot)\n> rather than making the future deployment of anything using this data\n> much harder since the server infos won't have it anymore?\n\nT and D lines were expensive.  Very expensive.\n\nThey are not used by existing Porcelains.\n\nIt is dubious if those lines are useful.\n\nThe information those lines were attempting to give Porcelains\nwere designed way before dumb-transport clients were completed,\nand it was purely a guesswork what _might_ be needed by them.\n\nFor example, I did not foresee that dumb-transport clients would\ngrab all the .idx files to see which packs are needed themselves\nwithout consulting T lines (which turns out to be the right\nthing to do anyway), and once they have the .idx file, clients\ncan do better computation themselves to pick which pack is the\nbest one to fetch without help from the T and D lines.\n\nFor example, if we implement the \"staggered overlapping packs\"\nyou suggested, the clients will face a choice when walking the\ncommit chain.  Two packs may give the object currently being\nsought after.  Which one to pick?  One strategy would be to pick\nthe one that contains least number of objects we already have.\nAnother would be to pick the one that contains the most number\nof objects we do not have yet.  This can be done with only\nhaving .idx files, and you need to have .idx files for both of\nthem to realize that you have a choice to begin with.\n\nIIRC, in your \"staggered packs\" approach, some recent objects\nare left unpacked and also in the latest pack.  Clients that\nhave all the objects in the latest pack are better off walking\nindividual commits, while other clients that are way behind are\nbetter off fetching the pack.  To help them, we would need to\ndescribe the object database differently from the way\nobjects/info/packs attempted with those T and D lines.  We need\nto say \"if you do not have these objects, do not walk individual\ncommits beyond this commit, even though they are available as\nloose objects, because you are better off grabbing this pack\ninstead\".\n\nFor these reasons, I feel that the whole thing should be\nstripped down first.  The improvements to the dumb-transport\nclients may need additional information to be computed by\nserver-info, but it is far more likely than not that those\nadditional information would be quite different from what T and\nD lines were giving them.  \n\nThe repacking strategy, the repacking program to prepare the\nrepository to be helpful to dumb-transport clients, the logic in\nthe clients to take advantage of that repacking strategy, and\nthe additional information server-info supplies to help that\nhappen, need to be designed together, and in this order.  The\nold T/D lines were developed in a wrong order --- we did not\nknow what the best repacking strategy was (and I suspect we\nstill don't) and these lines were done without knowing if they\nare useful.\n"}]}