[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 4588]  Item index too large in revision
From:       sf () tigris ! org
Date:       2015-08-25 13:21:32
Message-ID: 20150825132132.7A917540339 () sc157-tigr ! sjc ! collab ! net
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=4588






------- Additional comments from sf@tigris.org Tue Aug 25 06:21:32 -0700 2015 -------
Basically, a SVN repository is a database served through a long-running process.
Manipulating that DB without telling the server leads to all kinds of trouble.
Checking our documentation, I found that we don't make this fact clear enough
and updated the release notes for 1.8 and 1.9 accordingly.

To your first point: yes. svnadmin dump / load does not interact with the server
(which is partly a cause for problems you have been seeing).  There is no
indication that anything else went wrong.

To the second point: yes, building dependencies can be tedious and their docs
may be lacking ("APR" is the "Apache Portable Runtime", consisting of apr,
apr-utils and apr-iconv).  That's nothing SVN-specific, though.  For a CentOS
build of SVN 1.9, you might have a look at this one:

http://opensource.wandisco.com/centos/6/svn-1.9/RPMS/x86_64/subversion-1.9.0-1.src.rpm

There might be other packages available by now:

http://subversion.apache.org/packages.html#centos

To your last point, SVN 1.9 should be faster than 1.8 and have fewer bugs but I
don't expect any benefit in your conversion scenario. Given that your repository
seems to have only a few thousand revisions, I don't expect the performance
differences to be noticeable.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=3133974

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic