quoted
quoted
quoted
quoted
"MT" == Mike Taht [off-list ref] writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed....
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between related blobs/trees by also doing something like what I
described as "diff package", don't you?
We can just have a baseline file contain all the commit objects.
Then have the git "download on demand". The problem with diff
package is that I it is harder to merge with more than one diff.
I bet 90% of the time people sync to the repository head first
want to check out the last bits. And maybe reading some change
log to see what is changed.
So having all the commit object, the user will able to see
what is change and which version he we like to check out.
Then he can issue a command "download me all the objects is needed
for checkout the this commit". Download of demand should be
even better.
Chris
On Sat, Apr 16, 2005 at 12:19:22PM -0700, Junio C Hamano wrote:
quoted
quoted
quoted
quoted
quoted
"MT" == Mike Taht [off-list ref] writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed....
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between related blobs/trees by also doing something like what I
described as "diff package", don't you?
-
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
Junio C Hamano wrote:
quoted
quoted
quoted
quoted
quoted
"MT" == Mike Taht [off-list ref] writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed....
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between related blobs/trees by also doing something like what I
described as "diff package", don't you?
Yes... yes you could have files and diffs generated statically...
although something like a bittorrent server/client/frontend, call it
"gittorrent" (I hate being the first to make this pun) could walk the
hashes dynamically (
Ihave: sha,sha,sha,sha... Sendme: shaxxxxxxxxxxxxxxxxxxx
Hereswhatyouneedfromgit: file,file,file,diff,diff,diff,...)
--
Mike Taht
"It looks like blind screaming hedonism won out."
On Sat, 16 Apr 2005, Mike Taht wrote:
Junio C Hamano wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"MT" == Mike Taht [off-list ref] writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed....
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between related blobs/trees by also doing something like what I
described as "diff package", don't you?
Yes... yes you could have files and diffs generated statically...
although something like a bittorrent server/client/frontend, call it
"gittorrent" (I hate being the first to make this pun) could walk the
hashes dynamically (
Ihave: sha,sha,sha,sha... Sendme: shaxxxxxxxxxxxxxxxxxxx
Hereswhatyouneedfromgit: file,file,file,diff,diff,diff,...)
I'm actually working on a trivial HTTP client to do this. The user says
"get <commit-id> from <url>", and it gets that object, the associated
trees, and the associated blobs, skipping any that it already has.
This should save having a non-standard public-facing server process, and
be essentially as effective, at least once I have it using a single
connection for everything.
-Daniel
*This .sig left intentionally blank*