On Thu, Oct 4, 2018 at 3:03 PM Chris <devnullaccount_at_yahoo.se> wrote:
>
> (apologies for the top-posting, I really need to stop using this yahoo web interface which is useless with quoting)
>
> Thanks for all the replies. I'll try out what you outlined. There are unfortunately problems outside of my control that makes it worse and that is that for company-internal policy reasons, I'm not allowed direct access to the server, I'm only able to get a copy of the repo to work with and a promise that they can replace the repo with my modified version when I'm done. This might make some of the suggestions hard to work with, but I'll see if seems possible. Also, the server runs 1.8, and I have no authority to get it upgraded. I think I may have a chance to change the read permissions for the sync user though, so there's a ray of light somewhere in there :)
>
> W.r.t. Johan's question about the time consumption for dumping, I haven't been yet able to test it myself, I only got this as second-hand info from someone who did a dump of the repo last year, so I hope that is completely incorrect. Will try dumping as soon as I get my hands on a repo copy.
>
> Regarding why the repo is so large: my estimate from running some analysis on old revisions is that 90-95% of the data consists of beginners doing accidental commits of things that should not have been allowed to commit
>
Okay, good luck with those "operations". I wanted to add a couple more
bits of info:
- After dump+filter+load or svnsync-with-filtering (effectively
creating a new repository with an alternate history compared to the
original) your new repository will / should have a new UUID. This
effectively invalidates all existing working copies out there (which
keep track of the UUID they were a checkout from). So all users will
have to checkout new working copies.
- You can perfectly well use a 1.10 version of svnadmin or svnsync (or
svnrdump, to create a dumpfile from a remote server) to interact with
a 1.8 server / repository. So if using a more modern version of
svnadmin or svnsync is beneficial, you should use it :).
- A dump file can be (much) larger than the original repository
itself, depending on how the dump is created. That's because the
repository potentially uses deltification, compression and
"representation sharing". If you use the --deltas option for 'svnadmin
dump', it will be smaller, at the expense of cpu time for the
deltification. Usually people will not use the --deltas option when
sending it directly through a pipe (saving on the cpu cycles for
deltification), but when writing it to a file you should probably use
--deltas.
--
Johan
Received on 2018-10-04 16:27:07 CEST