Hi,
Here you go:
dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
commit dfa72fdb96befbd790f623bb2909a347176753c2
Author: Eric Wong <normalperson@xxxxxxxx>
Date: Fri Oct 24 22:53:52 2014 +0000
git-svn: reload RA every log-window-size
Despite attempting to use local memory pools everywhere we can,
(including our call to SVN::Ra::do_update and all subsequent reporter
calls), there does not appear to be a way to force the Git::SVN::Fetcher
callbacks to use a pool other than the per-SVN::Ra pool.
Git::SVN::Fetcher ends up using the main RA pool which grows
monotonically in size for the lifetime of the RA object.
Thus the only way to free that memory appears to be to destroy and
recreate the RA connection for at every --log-window-size interval.
This reduces memory usage over the course of fetching 10K revisions
using a test repository created with the script at the end of this
commit message.
.........
Cheers,
Valery
With best regards, Mr. Valery Yundin.
On 30 January 2015 at 00:34, Eric Wong <normalperson@xxxxxxxx> wrote:
> Valery Yundin <yuvalery@xxxxxxxxx> wrote:
>> Tested on:
>> git-svn version 2.3.0.rc2 (svn 1.8.11) - FAIL
>> git-svn version 2.2.2 (svn 1.8.10) - FAIL
>> git-svn version 1.8.4.5 (svn 1.8.11) - WORKS
>
> Thank you for that info. Do you think you can bisect which
> versions/revisions of git-svn introduced that failure for us? I don't
> have much time this part of the year for git-svn, but maybe it's related
> to the performance work we did around fall 2014.
>
> Thanks again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html