"Shawn O. Pearce" [off-list ref] writes:
Nicolas Pitre [off-list ref] wrote:
...
Here's something we didn't think about, but that occurred to me today
when reading this series: If we move the SHA-1 table out of the index
and into the packfile (like we are planning) dumb commit-walkers
(http-fetch) will have problems. Right now they download the
indexes of every available packfile to determine if they need to
download the corresponding packfile to obtain a needed object.
If we really care about older dumb clients, one option is to
generate not .idx but .idx2, and have a corresponding .idx only
to support them. But at that point, it's probably cleaner to
have an explicit option to produce .idx file of a particular
version, and tell people to pack public repositories they expect
older dumb clients to access with that option to keep things
backward compatible.
On Mon, 9 Apr 2007, Shawn O. Pearce wrote:
Junio C Hamano [off-list ref] wrote:
quoted
"Shawn O. Pearce" [off-list ref] writes:
quoted
Nicolas Pitre [off-list ref] wrote:
...
Here's something we didn't think about, but that occurred to me today
when reading this series: If we move the SHA-1 table out of the index
and into the packfile (like we are planning) dumb commit-walkers
(http-fetch) will have problems. Right now they download the
indexes of every available packfile to determine if they need to
download the corresponding packfile to obtain a needed object.
If we really care about older dumb clients, one option is to
generate not .idx but .idx2, and have a corresponding .idx only
to support them. But at that point, it's probably cleaner to
have an explicit option to produce .idx file of a particular
version, and tell people to pack public repositories they expect
older dumb clients to access with that option to keep things
backward compatible.
Sure, fine. But I think you missed my point above - right now if
we move the SHA-1 table out of the .idx file I'm not sure we know
how to support the dumb clients *at all*. Even if they understand
the latest-and-greatest file formats...
The table could live in both the pack and the index for those repos
expected to be exportable through dumb protocols.
Nicolas
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Nicolas Pitre [off-list ref] wrote:
...
Here's something we didn't think about, but that occurred to me today
when reading this series: If we move the SHA-1 table out of the index
and into the packfile (like we are planning) dumb commit-walkers
(http-fetch) will have problems. Right now they download the
indexes of every available packfile to determine if they need to
download the corresponding packfile to obtain a needed object.
If we really care about older dumb clients, one option is to
generate not .idx but .idx2, and have a corresponding .idx only
to support them. But at that point, it's probably cleaner to
have an explicit option to produce .idx file of a particular
version, and tell people to pack public repositories they expect
older dumb clients to access with that option to keep things
backward compatible.
Sure, fine. But I think you missed my point above - right now if
we move the SHA-1 table out of the .idx file I'm not sure we know
how to support the dumb clients *at all*. Even if they understand
the latest-and-greatest file formats...
--
Shawn.