[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] svnadmin build-repcache command

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 27 Mar 2020 14:41:31 +0100

On Thu, Mar 26, 2020 at 08:32:38PM +0000, Daniel Shahaf wrote:
> What I'm worried about is that we'll apply the "backwards compatibility
> until 2.0" promise to something we shouldn't. As I said, issues of
> this nature can't generally be found by tests; they can only be found
> by code review.

I'm not worried about that. After reading through the patch I don't see
any reason why we would not want to commit to supporting this feature.

Do you have concrete concerns? I can't see any downsides.
So far, I believe this new subcommand will be very useful.

The only existing alternative is a full dump/load which is expensive
to perform on large repositories.
I've seen several cases in recent years were servers were upgraded but
admins decided against doing a full dump/load cycle of repositories
sized in the GB/TB range because the perceived benefits didn't justify
the extra effort.

I know of at least two cases where rep-sharing was temporarily or perhaps
even permanently disabled after SHA1 collisions were committed (one case
is webkit, I learned about another case via elego's SVN support).
These repositories are now growing faster than they would if rep-caching
could be re-enabled easily.
Received on 2020-03-27 14:41:49 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.