SVN timing again

[Kevin Puetz]

Thiago Macieira wrote:

> Stephan Kulow wrote:
>>What has this to do with the question I asked?
> 
> This:
> 
>>We can update the server at any time. It would require a downtime of
>> less than half an hour, even if the binary representation of the repo
>> changes. All that is required is taking a snapshot to another computer,
>> migrate it there, play it back to svn.kde.org, shutdown svn (here comes
>> the downtime), create a dump of the changes between the snapshot and
>> HEAD, move the new repository over the old, update subversion, apply
>> the dump and restart subversion.
> 
> There's a downtime involved. I had no idea how long that downtime would
> be, so I thought it would be best if we did it all at once, than to have
> another 12-hour downtime to dump and reload the database.
> 
> If it's as short a downtime as you say, then it doesn't matter.
> 

What he's saying is that any major conversion work for a change of SVN
repository format (ie, doing the optional conversion to xdelta in 1.2 to
get faster annotate) can be done while the main server is still up
read-write, because it's easy to grab the commits that came in during the
period when you were converting old history and tack them on the end.

Basically
svnlook youngest ./repository
# OK, HEAD is revision n

svnadmin dump -r 0:n foo > dumpfile
svnadmin load foo.new < dumpfile
# 12 hours passes
# shut down svn access
svnadmin dump --incremental -r n+1:HEAD > dump.new
# get the commits done in the last 12 hours - shouldn't be *too* many
svnadmin load foo.new < dump.new
mv foo foo.old
mv foo.new foo
#restart SVN

so things only have to be down for the replay of the commits that came in
during the main conversion. I suppose if the initial conversion took a
*really* long time one could even iterate the process more than once, but
that seems silly - even a whole day's worth of commits shouldn't take long
to process :-)