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.