Nico Kadel-Garcia wrote on Thu, Jun 30, 2011 at 08:59:10 -0400:
> 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.
Suppose that, prior to committing a txn on the master, you duplicate
that txn on (but not commit it to) the slave. Would that allow you to
manually pull the master out of service and promote the slave to
Received on 2011-06-30 15:13:51 CEST