> On Aug 16, 12:36 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
>> Please turn off both antivirus and firewall, then try again.
>> It does not mean that if the 32-bit Subversion clients work that Norton
>> doesn't interfere with the x64 version either.
>> So my best guess (since you admitted using one) would be your virus
>> scanner/firewall interferring with (and changing) the data packets.
> I'd actually tried that earlier, but I just tried it again. Same
> If it were a non-UTF-8 character, I'd imagine that TSVN on the 32-bit
> XP would fail also. These repositories have been SVN from day one so I
> don't know how a non-UTF-8 character would have snuck in.
> Because Subclipse works, I'm not stuck, but I miss the greater power
> of TSVN. Again, thank you for giving me a hand with this!
I won't deny the possibilty that an x64 build may show some problems
that the 32-bit build does not. But since some Subversion developers
also use an x64 build (most of them use Linux), I would assume that such
a bug would have been found already.
Are you absolutely sure you disabled the virus scanner/firewall
*completely? I'm just asking because most of those 'things' allow you to
disable certain 'features' but then in the background still mess around
because they think that users (even though they configured it) didn't
*really* want to disable it.
For example, we have to use Kapersky in our office, and that also messes
around, even if all ports which it should monitor are removed. To get
svn+ssh:// working again, you have to completely disable it, and I mean
If that doesn't help, you should maybe ask on the Subversion mailing
list for help: the error message is thrown by the Subversion library
which TSVN uses, so it's something internal to the library, not the TSVN
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-08-17 09:29:26 CEST