[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-12-10 23:29:39 CET

On 12/10/06, David Summers <david@summersoft.fay.ar.us> wrote:
> I'm now trying to get the svnsync to work in such a situation and running
> into a bit of a snag. When I try to run the "svnsync sync
> https://dsum/repos/test" command on the slave (dsum), it asks me for
> username/password on the slave server and then on the master server and
> then it says:
> svnsync: DAV request failed; it's possible that the
> repository's pre-revprop-change hook either failed or is non-existent
> svnsync: At least one property change failed; repository is unchanged
> I'm thinking that the svnsync command is now also getting re-directed to
> the master in a kind of "loop" where when I try
> to svnsync the slave, it is now getting re-directed to the master to try
> to run the svnsync there.
> I'm hoping I can just tweak my configuration on the master or slave and
> fix this but am uncertain how to proceed.
> Any thoughts/suggestions/pointers?

Note that you can't do any of the svnsync commands against the slaved
WebDAV instance as when replay tries to make a commit, it'll just go
back to the master. svnsync against a file:// URL would work, I guess.
 Or, setup an entirely separate Location (that isn't visible to your
clients) that you can do the svnsync to.

I haven't really sat through how svnsync would work; hence why the
dump/load cycle in the email. I think svnsync would work, but I
haven't tried.

HTH. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 10 23:29:56 2006

This is an archived mail posted to the Subversion Dev mailing list.