Re: git-svn: why fetching files is so slow

Eric Wong [off-list ref] writes:

Pazu [off-list ref] wrote:

quoted

Eric Wong <normalperson <at> yhbt.net> writes:

quoted

git-svn transfers full files, and not deltas.  I'll hopefully have a
chance to look into improving the situation for slow links this weekend.

Yes, but why would that make fetching the first revision slower? In this
situation, both svn and git-svn would have to fetch full files. Maybe git-svn
isn't using gzip compression or http pipelining?

Even for the initial transfer, the tree is bundled into one big delta
(at least over https).

Do you mean that "one big delta" saves duplicates across copies
inside the tree (e.g. svn tags and branches can be expressed as
a mostly identical copies of each other), or do you mean "one
full file at a time" requests are killing us, compared to a such
single transfer of "one big delta"?

Junio C Hamano [off-list ref] wrote:

Eric Wong [off-list ref] writes:

quoted

Pazu [off-list ref] wrote:

quoted

Eric Wong <normalperson <at> yhbt.net> writes:

quoted

git-svn transfers full files, and not deltas.  I'll hopefully have a
chance to look into improving the situation for slow links this weekend.

Yes, but why would that make fetching the first revision slower? In this
situation, both svn and git-svn would have to fetch full files. Maybe git-svn
isn't using gzip compression or http pipelining?

Even for the initial transfer, the tree is bundled into one big delta
(at least over https).

Do you mean that "one big delta" saves duplicates across copies
inside the tree (e.g. svn tags and branches can be expressed as
a mostly identical copies of each other), or do you mean "one
full file at a time" requests are killing us, compared to a such
single transfer of "one big delta"?

One full file at a time requests are definitely killing us (over slow
links, at least).  I'm not sure how/if duplicates inside a requested
tree are optimized on the server side.

--