Re: Issue with svnsync / feature request for svnadmin

Stephen Connolly wrote on Fri, 13 Nov 2009 at 09:10 -0000:
> What we have noticed is that approx once per week, the network
> disconnect occurs inbetween committing the transaction and updating
> the metadata on rev 0, e.g. svnsync has copied rev 60782, but the
> metadata has not been updated before svnsync's connection terminated.
> So the next time svnsync runs it sees that the repository has a higher
> transaction number than the last copied revision, and as a result it
> bombs out, and that repository falls out of sync.
>

AFAIK, svnsync should handle this case without bombing out (using
svn:sync-currently-copying).

> Currently, our cron script sends an email to inform that a repository
> has fallen out of sync, I ssh in to the US mirror and roll back the
> current transaction to the last-copied (by deleting the files in the
> FSFS system) and trigger an svnsync again.

I can't imagine what problem you might have that would be fixed by deleting
files from the FSFS. Even the typical "edit the FSFS by hand" scenarios
don't involve this.

(Also, what exactly is 'roll back the current transaction'? I suspect I do
not understand correctly your description of the scenario+workaround.)

> I do not like having to do this by hand.  It is error prone, and AFAIK
> once I upgrade to SVN version 1.6, I will no-longer be able to perform
> the roll-back if I've packed the FSFS shards.

Packing doesn't happen automatically, and only affects completed
shards (i.e., as long as the next revision will be in shard X, that
shard will remain unpacked).

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2417897

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-14 11:15:34 CET