Changes mark shows on nonenglish comments. about svn-scm HOT 12 CLOSED

Should be working in v1.0.1

from svn-scm.

Hi @v4a26 ,

I will have a look into this for you.

from svn-scm.

Hi @v4a26

Looks like i dont do any checks on character encoding. Think i just assumed that everyone was going to be using utf8.

I will add encdoing checks when i roll out my own svn implimentation. Currently i rely on svn-spawn which limits the config i can currently do.

from svn-scm.

Thx.

from svn-scm.

I don't know if it falls into this issue. Despite seing the decoration for changes for every line that contains an Umlaut (german setting, using iso8859-15 as char set) which is related to this issue, i also see a change indicator in every file at the last line. It always shows that the last empty line was added in the local copy.
None of the files were actually changed. Clean from the repository.

from svn-scm.

Yeah, i have noticed that today on 1.18. Looks like the editor is adding a new line.

It added new lines to 3 of my open files. Cant seem to get it to do it again.

from svn-scm.

This has been done and will be available as part of v1.0.0.

from svn-scm.

Hi @magic-k @v4a26

Can you send me a sample of the comments you are having issues with so i can test them out please?

from svn-scm.

Try this one. Codepage: windows 1251.
Untitled-1.zip

from svn-scm.

Thanks!

from svn-scm.

@JohnstonCode For a while everything was fine, but right now I have a similar problem.

1.19.1 - VSCode Version:
Windows 7 - OS Version:
1.5.0 - Extension Version:
Russian; CP1251 - System Language:

The problem is similar to the topic. Gutter show that there are some changes in lines with Russian letters.

In my working repository, only a few characters cause problems. They marked bold in an example below.

абвгдеёжзийклмнопрстуфхцчшщъыьэю я
АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ

Seems like used wrong offset in Windows-1251.

I tried to reproduce the problem but got the different result. All characters are corrupted.

Here the test file.
myTest.zip

I have no idea why results are different, but anyway something gone wrong.

from svn-scm.

@v4a26 encoding seems to be a reoccurring pain point.

I will have to think of another way to get it work check/work

from svn-scm.