On Wed, Jun 29, 2011 at 12:27 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> Hi Waseem,
>
> On Wed, Jun 29, 2011 at 6:17 PM, Waseem Bokhari
> <waseem.bokhari_at_netsoltech.com> wrote:
>>
>> Hi Guys!
>>
>> We are using 3rd party software that take (Copy/Paste)
>> Backup of all databases of SVN on differential basis. I have some confusion.
>>
>> What's in all these *.txn folders (33740-q3q.txn, 1757-1d0.txn,
>> 33753-q43.txn) Please guide ? Are they of any use? What is their importance
>> for Us? Could they be ignored or excluded?
>>
>> For some reason new set of files that are being dropped into these folders
>> and they happen to be Alternate data streams, and which we do not seem to be
>> able to pseudo mirror.
>>
>> Thanks in
>
> The only safe way to run a backup of a Subversion repository is to use the
> 'svnadmin hotcopy' functionality or equivalent functionality in other
> Subversion clients.
> With kind regards,
>
> Erik.
Unfortunately, svnadmin hotcopy does not duplicate the contents of
symlinks, although it now does duplicate the symlink. It also ignores
hard links. (Not that they're common, just saying.) Unfortunately,
it's also bloody slow to replicate the *whole database* of a bulky
repository, and has no incremental backup function.
svnsync does not give you "identical" repositories, merely
synchronized. This means that if the first repo accepts commits that
the second repo didn't get, and you activate the second repo with the
same uuid to try and make the change invisible to the users, they will
have locally applied revisions that do not match your failover
repository. Chaos ensues: this is the "split-brain" problem.
All of those issues seem to be resolved with Wandisco's "Multisite"
tool. It's commercially available. There are some risks of large
distributed networks becoming "split-brained", but for , say, 3 well
managed nodes, that should be easy to avoid. It's described at
http://www.wandisco.com/subversion/multisite/. I've not personally
used it, but since Wandisco seems to be the major commercial
maintainer of Subversion now, I'd have some confidence in it.
Received on 2011-06-30 14:59:41 CEST