On Thu, Jan 13, 2011 at 11:40 PM, Sam Vilain <sam@xxxxxxxxxx> wrote: > On 14/01/11 00:39, Luke Kenneth Casson Leighton wrote: >> and change that graph? Âare you _certain_ that you can write an >> algorithm which is capable of generating exactly the same mapping, >> even as more commits are added to the repository being mirrored, or, >> does that situation not matter? > > For a given set of start and end points, and a given sort algorithm, > walking the commit tree can yield deterministic results. excellent. out of curiosity, is it as efficient as git pack-objects for the same start and end points? > Did you look at any of the previous research I linked to before? i've been following this since you first originally started it, sam :) it would have been be nice if it was a completed implementation that i could test and see "for real" what you're referring to (above) - the fact that it's in perl and has "TODO" at some of the critical points, after trying to work with it for several days i stopped and went "i'm not getting anywhere with this" and focussed on bittorrent "as a black box" instead. if i recall, the original gittorrent work that you did (mirror-sync), the primary aim was to rely solely and exclusively on a one-to-one direct link between one machine and another. in other words, whilst syncing, if that peer went "offline", you're screwed - you have to start again. is that a fair assessment? please do correct any assumptions that i've made. because on the basis _of_ that assumption, i decided not to proceed with mirror-sync, instead to pursue a "cache git pack-objects" approach and to use bittorrent "black-box-style". which i demonstrated (minus the cacheing) works perfectly well, several months back. in this way (i know i didn't reply earlier - apologies), there is absolutely no need to "take bittorrent apart", no need to modify it, tinker with it, adjust it, redesign it, learn from it "for inspiration" - you just get on with it, using the code, protocol and everything about it as a black-box. "get this file to everyone and anyone wot needs it". as well, after nicolas and others went to all the trouble to explain what git pack-objects is, how it works, and how damn efficient it is, i'm pretty much convinced that an approach to uniquely identify, then pick and cache the *best* git pack-object made [by all the peers requested to provide a particular commit range], is the best, most efficient - and importantly simplest and easiest to understand - approach so far that i've heard. perhaps that's because i came up with it, i dunno :) but the important thing is that i can _show_ that it works (http://gitorious.org/python-libbittorrent/pybtlib - go back a few revisions) so - perhaps it would help if mirrorsync was revived, so that it can be used to demonstrate what you mean (there aren't any instructions on how to set up mirrorsync, for example). that would then allow people to do a comparative analysis of the approaches being taken. i'd be *very* interested - and i'm sure that there are others likewise equally as interested - to see if the mirrorsync "commit tree walking" algorithm can come up with a more efficient method of transferring git repositories than git pack-objects can. l. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html