> On Oct 19, 2014, at 18:16, Eric Wong wrote:
>
> Jakob Stoklund Olesen wrote:
>> If cached_mergeinfo is using too much memory, you can probably drop
>> that cache entirely. IIRC, it didn't give that much of a speed up.
>>
>> I am surprised that it is u
> On Oct 18, 2014, at 19:33, Eric Wong wrote:
>
> Eric Wong wrote:
>> This reduces hash lookups for looking up cache data and will
>> simplify tying data to disk in the next commit.
>
> I considered the following, but GDBM might not be readily available on
> non-POSIX platforms. I think the o
On Oct 18, 2014, at 21:12, Eric Wong wrote:
>> I am somwhat worry about the dramatic difference between the two
>> .svn/.caches -
>> check_cherry_pick.yaml is 225MB in one and 73MB in the other, and also
>> _rev_list.yaml is opposite - 24MB vs 73MB. How do I reconcile that?
>
> Calling patterns
> On Sep 19, 2014, at 1:25, Eric Wong wrote:
>
> Hin-Tak Leung wrote:
>
>> - I know I can probably just "read the source", but I'd like to know
>> why .git/svn/.caches is even larger than .git/objects (which supposedly
>> contains everything that's of interest)? I hope this can be documented
On Apr 22, 2014, at 11:54 AM, Eric Wong wrote:
> Jakob Stoklund Olesen wrote:
>> Subversion can put mergeinfo on any sub-directory to track cherry-picks.
>> Since cherry-picks are not represented explicitly in git, git-svn should
>> just ignore it.
>
> Hi, was git
Subversion can put mergeinfo on any sub-directory to track cherry-picks.
Since cherry-picks are not represented explicitly in git, git-svn should
just ignore it.
Signed-off-by: Jakob Stoklund Olesen
---
perl/Git/SVN.pm | 29 +
1 file changed, 13 insertions(+), 16
erged
branches whose ranges haven't changed, and remove a common prefix of
ranges from other merged branches.
This speeds up "git svn fetch" by several orders of magnitude on a large
repository where thousands of feature branches have been merged.
Signed-off-by: Jakob Stoklund Olesen
7 matches
Mail list logo
