On Oct 19, 2014, at 18:16, Eric Wong normalper...@yhbt.net wrote:
Jakob Stoklund Olesen stokl...@2pi.dk 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 using a lot
On Oct 18, 2014, at 21:12, Eric Wong normalper...@yhbt.net 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?
On Oct 18, 2014, at 19:33, Eric Wong normalper...@yhbt.net wrote:
Eric Wong normalper...@yhbt.net 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
On Sep 19, 2014, at 1:25, Eric Wong normalper...@yhbt.net wrote:
Hin-Tak Leung ht...@users.sourceforge.net 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
On Apr 22, 2014, at 11:54 AM, Eric Wong normalper...@yhbt.net wrote:
Jakob Stoklund Olesen stokl...@2pi.dk 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
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 stokl...@2pi.dk
---
perl
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 stokl...@2pi.dk
---
perl/Git/SVN.pm | 29 +
1 file changed, 13
7 matches
Mail list logo
