On 2010-09-25 14:43, Daniel Shahaf wrote:
> Ramkumar Ramachandra wrote on Sat, Sep 25, 2010 at 11:59:49 +0530:
>> Agreed, these modules should not be part of the core. However, in the
>> case of Subversion, there absolutely NO way to get/ back up the
>> revision history data* [5].
>
> svnsync.
On a side note, svnsync happens to be relatively slow. I tried to svnsync
the ASF repos once (for huge test data). The slowness of svnsync made it
practically unfeasible to pull off. I ended up downloading a zipped dump and
'svnadmin load'ing that dump. Even with a zipped dump already downloaded,
'unzip | svnadmin load' took a few *days* to load the 950.000+ revisions.
(And someone rebooted that box after two days, halfway through, grr. Took
some serious hacking to finish up without starting over.)
So, that experience tells me that svnsync and svnadmin dump/load aren't
close to optimal, for example compared to a straight download of 34 gigs
that the ASF repos is... Anything that could speed up a remote dump/load
process would probably be good -- while I don't know any details about svnrdump.
My two cents: Rephrasing everything into the dump format and back blows up
both data size and ETA. Maybe a remote backup mechanism could even break
loose from discrete revision boundaries during transfer/load...
In contrast, the speed of a remote 'svn log' just amazes me. It's pretty
darn fast to get all the commit logs of a repos. So between that and getting
the rev content as well there's some big speed loss.
Heh, that's my reply to a single-word statement ;)
~Neels
P.S.: If the whole ASF repos were a single Git WC, how long would that take
to pull? (Given that Git tends to take up much more space than a Subversion
repos, I wonder.)
Received on 2010-09-27 03:40:51 CEST