You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2006/12/10 22:29:39 UTC
Re: DAV-MIRROR
On 12/10/06, David Summers <da...@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
Re: DAV-MIRROR
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Sun, 10 Dec 2006, Justin Erenkrantz wrote:
> On 12/10/06, David Summers <da...@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.
>
I set up a separate Location (https://dsum/repos/test-sync/) pointing to
the same physical test repository:
$ svnsync sync https://dsum/repos/test-sync/
svnsync: Malformed URL for repository
OK, I'll see if I can try some other options.
Thanks.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org