On 19.08.2014 02:17, Andy Levy wrote:
> Why risk the race condition at all? Use svnsync to populate a new
> 1.8-format repository, install the requisite hook scripts to replay
> the transactions coming into the old repository into the new one, then
> switch your server's configuration to point at the new copy when
> you're ready to cut over.
This solution has the same race as the dump-based solution. You still
have to block commits to the repository for a short period to do the
final sync before switching.
> On Mon, Aug 18, 2014 at 7:43 PM, Eric Johnson <eric_at_tibco.com> wrote:
>> I've got a crazy idea for minimizing downtime - since the servers are not
>> being constantly bombarded with commits, I'm thinking that I can just do a
>> dump/load on the fly, and see if any commits came in while the dump was
>> happening, and if they did, try the dump again.
>> That is:
>> STARTREV = `svnlook youngest repodir/$REPONAME`
>> svnadmin create reload/$REPONAME
>> svndump repodir/$REPONAME | svnadmin load reload/$REPONAME
>> ENDREV = `svnlook youngest repodir/$REPONAME`
>> if "$STARTREV" == "$ENDREV"; then
>> mv repodir/$REPONAME older/$REPONAME
>> mv reload/$REPONAME repodir/$REPONAME
>> # and if the above didn't match, repeat the above until success.
>> There's the tiniest bit of a race condition at the very end. But is it safe
>> to do an svnadmin dump on a live repository?
Dumping a live repository is perfectly safe. When the first (complete)
dump and load finish, you don't have to retry the whole dump if there
were any commits to the source repository; just do an incremental dump
and incremental load.
In other words:
1. Perform a full dump from [old] and load into [new]
2. Make [old] read-only
3. If there were any commits during (1), perform an incremental dump
from [old] and load into [new]
4. Switch the repositories and restart the server to purge in-memory
The solution with svnsync is similar, except that instead of running
'svnadmin dump/load' you'll run 'svnsync'.
Both solutions have a downside: they will not notice revision property
changes (e.g., log message changes) in revisions that have already been
synced to the new repository. There are ways to solve that, but by far
the easiest way is to block revprop changes in the pre-revprop-change
hook in the old repository while you're doing the upgrade.
Just remember to always restart the server after switching from the old
to the new repository to remove stale caches. (Yes, we're currently
working on making that mostly unnecessary in 1.9.)
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
Received on 2014-08-19 09:05:56 CEST