On 27.08.2016 10:59, Stefan Fuhrmann wrote:
On 22.08.2016 11:38, Radek Krotil wrote:
The repository contains 334243 revisions total. As suggested by
Stefan, I did the grep on the problematic repo file. The rev 203908
is about 231 MB big. This confirms my suspicion that the problem is
related to big revision data.
Well, that is at least conceivable: Larger revisions
with many changed nodes come with larger index
information. There might be bugs along the line of
"this time we need one more page than usually".
Update: It seems that is exactly what is happening.
Whenever a pack would contain >300000 "items",
or roughly 150 changes / rev on average, pack
will always fail.
From what I can see, no data will be corrupted. You
may even retry packing with a fixed version of svnadmin
and the process should complete just fine.
I'm now able to reproduce the issue and fixes should
be available with the next 1.9.x release.
A workaround is possible with the attached patch
(you may raise the limit even further if need be and
you are using 64 bit binaries).
-- Stefan^2.
Index: subversion/libsvn_fs_fs/pack.c
===================================================================
--- subversion/libsvn_fs_fs/pack.c (revision 1757331)
+++ subversion/libsvn_fs_fs/pack.c (working copy)
@@ -87,7 +87,7 @@
/* Maximum amount of memory we allocate for placement information during
* the pack process.
*/
-#define DEFAULT_MAX_MEM (64 * 1024 * 1024)
+#define DEFAULT_MAX_MEM (512 * 1024 * 1024)
/* Data structure describing a node change at PATH, REVISION.
* We will sort these instances by PATH and NODE_ID such that we can combine
