threads / discuss / 21988

git-svn mergeinfo support performance problem

Subject: git-svn mergeinfo support performance problem

## tl;dr

3 messages between Dec 19, 2009 and Dec 20, 2009.

replies: 2people: 2as markdown or json

Andrew Myrick· Dec 19, 2009, 01:08 UTC · lore

I've been testing git-svn v1.6.6-rc3's mergeinfo support on a large svn repository (60,000+ revisions, 20+ GiB) that uses a very branch-heavy integration model in which every change gets its own branch before being committed to trunk. As a result of the model, there are currently over 1000 lines in the svn:mergeinfo property on trunk. Unfortunately, with the current implementation, git svn fetch takes more than a minute per revision pouring through all of those merge tickets; obviously, this is too slow to be usable for my repository.

Are there any ideas on how git svn fetch can be sped up when facing hundreds of mergeinfo properties? Alternatively, would it be possible to add an argument that would ignore the merge info? Or, is there any maintenance I could perform on the svn repository that would help reduce the amount of work that git-svn must do? In the meantime, I'll have to stick with git 1.6.5.*.

Regards, Andrew

P.S. This is my first post to the list. My apologies if this issue has already been discussed and I did not see it in the archives, or if I have missed a more formal mechanism for filing bug reports.

Johan 't Hart· Dec 20, 2009, 00:28 UTC · re: Andrew Myrick · lore

Re: git-svn mergeinfo support performance problem

Andrew Myrick schreef:

Show 6 quoted lines

> I've been testing git-svn v1.6.6-rc3's mergeinfo support on a large
> svn repository (60,000+ revisions, 20+ GiB) that uses a very
> branch-heavy integration model in which every change gets its own
> branch before being committed to trunk.  As a result of the model,
> there are currently over 1000 lines in the svn:mergeinfo property on
> trunk.

Just wondering: Isnt this workflow stalling svn itself alot too?

And also: Do you delete the branches after you reintegrated them? If so, I think its safe for you to cleanup the svn mergeinfo once in a while. That should not affect 'svn log -g' because the mergeinfo is still there in older revisions. I think svn benefits from this too...

Andrew Myrick· Dec 20, 2009, 00:39 UTC · re: Johan 't Hart · lore

Re: git-svn mergeinfo support performance problem

On Sat, Dec 19, 2009 at 4:28 PM, Johan 't Hart <johanthart@gmail.com> wrote:

Show 10 quoted lines

> Andrew Myrick schreef:
>>
>> I've been testing git-svn v1.6.6-rc3's mergeinfo support on a large
>> svn repository (60,000+ revisions, 20+ GiB) that uses a very
>> branch-heavy integration model in which every change gets its own
>> branch before being committed to trunk.  As a result of the model,
>> there are currently over 1000 lines in the svn:mergeinfo property on
>> trunk.
>
> Just wondering: Isnt this workflow stalling svn itself alot too?

Nope, svn seems to handle it fine.

Show 5 quoted lines

> And also:
> Do you delete the branches after you reintegrated them? If so, I think its
> safe for you to cleanup the svn mergeinfo once in a while. That should not
> affect 'svn log -g' because the mergeinfo is still there in older revisions.
> I think svn benefits from this too...

We do not delete branches after they've been reintegrated. Bug fix and feature branches can get reintegrated into multiple release branches, so it's not obvious when a branch can be deleted. There's already enough process overhead that it's simpler just to leave all of the branches around. Since this doesn't seem to affect svn's performance, we haven't really worried about it.

-Andrew