Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Arthur,
Arthur Barrett wrote:
>> As stated above, it's not possible to simply replace some binary.
>> About reinventing the wheel... it's not really proper to use native
>> libraries or binaries in a cross-platform java app (it breaks
>>
>>
> the whole concept of Java), so in this particular case it'sinevitable.
>
> That is what I thought until recently. SVN is EXTREMELY popular with
> Eclipse users (another Java IDE) and the 'standard' SVN client for
> Eclipse is a 3GL one (called using JNI from Eclipse). There is an
> experimental pure-java SVN client but it is largely unused. Since SVN
> is so popular with SVN users and the most popular SVN plugin for the
> most popular Java IDE is not 'pure java' I now think that Java
> programmers just use this argument when it suits them and ignore it when
> it doesn't.
>
Eclipse, although Java-based, is actually as platform dependent itself
as the native SVN library that it uses as it relies on JNI bindings for
its GUI library (SWT), so in that case it doesn't limit the app's
portability further.
I don't think users generally care about the implementation as long as
it works for them. For the developer though, compiling native code for
all possible platforms that Java can run on is tedious and also in some
cases more or less impossible... (extreme example: how to compile and
test JNI native code for IBM's System i or System z, when you're a
standalone developer with access to nothing but a standard PC?)
But, enough with the native vs. VM war. :)
>>> In SmartCVS 7 under project->Settings on the Text File
>>>
>> Encoding tab there are some options you can try. If you
>> cannot find any setting that works with the server in unicode
>> mode then I can use the SmartCVS client identifier to
>> automatically adjust the CVSNT Server to convert the encoding
>> (bug5479).
>>
>>>
>>>
>> I have tried setting the text file encoding to UTF-8 (not
>> proper, as the
>> files themselves more often are stored in iso-8859-1, but it actually
>> varies), and that didn't have any effect on the filename encoding
>> (filenames are still garbled when the server is in Unicode
>> mode), which
>> is what one would expect.
>>
>
> In the prefs I can see two settings:
> 1) Encoding for local text files
> 2) Text file encoding in the Repository
>
> Which one did you try? I can't seem to find any documentation on them
> at all. I am hoping that one or both is really referring to the 'text
> filename encoding' rather than the contents.
>
In the project checkout dialog, under "Text file encoding" (default
settings can be found in Preferences under Project->Default project), I
selected the following:
Encoding for local text files: UTF-8
Text file encoding in the repository: Unicode (UTF-8)
It still does not change the way filenames are treated ("international"
characters are still corrupted), so I think it's safe to say that these
options only concern the encoding of the contents of the text files, and
not their filenames.
>> The trace logs you requested have been sent to support...
>>
>
> Thanks - it's going to be a couple of weeks before anything further
> happens because I'm away from the office until the 12th, and besides all
> CVSNT work is on hold until EVS is released.
>
Okay. :) Thanks for addressing this, and for CVSNT generally.
Cheers,
- Erik