On Sat, 2010-11-27 at 21:19 +0100, Ævar Arnfjörð Bjarmason wrote:
To me, the use-case wouldn't be because I /can't/ use existing methods,
it's because I /don't want to/ use existing methods :)
p2p tends to imply:
- Resume-able downloads
- Downloads from multiple sources at the same time
- Transparently using an alternative source if one becomes unavailable
- Load-balancing
- referencing/linking based on "what it is" instead of "where it is"
The reason this stuff isn't a big itch for anybody is that these
problems tend to come about when cloning, which doesn't really happen
that often. When there's a new release, fetching the latest
release-tag /might/ bring about the same needs, though in my experience
"there's a new release" generally means nothing to me, since I check if
there's a new release by running "git remote update" and looking for new
tags, merging with my local patches if I see a relevant one.
I'm not convinced that any of this is something which is git's job, so
much as it sounds like something which could benefit from another
transport layer that git can optionally tie into. Sure, these could be
developed together (p2p with git in mind), but adding a giant p2p
section to the git codebase sounds like bloat.
I want my version control software to use p2p concepts for efficiency. I
don't want my version control software to be a p2p client any more than
I want my text-editor to be a mail client.
(In case it's not clear, I am in favour of p2p ("gittorrent")-like
functionality being in git)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html