On Fri, May 13, 2011 at 2:07 PM, Richard Hipp wrote:
>
>
> On Fri, May 13, 2011 at 1:27 PM, Martin Gagnon wrote:
>
>> On Fri, May 13, 2011 at 1:15 PM, Richard Hipp wrote:
>> >
>> >
>> > On Fri, May 13, 2011 at 1:05 PM, Martin Gagnon
>> wrote:
>> >>
>> >> This particular problem occur since fos
abf5222] 2011-05-13 17:13:38 UTC
--%<---
--
Martin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/
On Fri, May 13, 2011 at 1:27 PM, Martin Gagnon wrote:
> On Fri, May 13, 2011 at 1:15 PM, Richard Hipp wrote:
> >
> >
> > On Fri, May 13, 2011 at 1:05 PM, Martin Gagnon wrote:
> >>
> >> This particular problem occur since fossil set the codepage to 65001.
> >> Since this, echo to console all wo
On Fri, May 13, 2011 at 5:05 PM, Benoit Mortgat wrote:
> I got X'[...] 6E 74 E9 65 [...]'
>
> (the [...] correspond to an even number of hexadecimal digits of course and
> spaces are added for readability)
>
> As you can see this is not valid UTF-8, so your guess is correct.
That's normal behav
On Fri, May 13, 2011 at 1:15 PM, Richard Hipp wrote:
>
>
> On Fri, May 13, 2011 at 1:05 PM, Martin Gagnon wrote:
>>
>> This particular problem occur since fossil set the codepage to 65001.
>> Since this, echo to console all work, but now I have this problem when I
>> commit.
>
> Please try this
On Fri, May 13, 2011 at 1:05 PM, Martin Gagnon wrote:
> This particular problem occur since fossil set the codepage to 65001.
>
> Since this, echo to console all work, but now I have this problem when I
> commit.
>
Please try this new build:
fossil-w32-20110513171338.zip
Let me know how i
This particular problem occur since fossil set the codepage to 65001.
Since this, echo to console all work, but now I have this problem when I
commit.
--
Martin
Le 2011-05-13 à 12:45, Richard Hipp a écrit :
>
>
> On Fri, May 13, 2011 at 12:41 PM, Martin Gagnon wrote:
>
> I got same resu
On Fri, May 13, 2011 at 12:41 PM, Martin Gagnon wrote:
>
> I got same result as my last test with previous version:
>
Do I understand correctly that the windows-i18n branch is working for you?
Or is there some issue in the text below that I have overlooked?
>
>
> --%<-
On Fri, May 13, 2011 at 11:49 AM, Richard Hipp wrote:
> I18N windows users: please try this version:
>
> http://www.fossil-scm.org/download/fossil-w32-20110513154610.zip
>
> This newer version translates the UTF8 used internally by Fossil into the
> code page obtained from GetConsoleCP() prio
I18N windows users: please try this version:
http://www.fossil-scm.org/download/fossil-w32-20110513154610.zip
This newer version translates the UTF8 used internally by Fossil into the
code page obtained from GetConsoleCP() prior to displaying the text.
Formerly, the UTF8 was being translated
Actually it is nearly impossible to rely on a command line on windows to
show data in the encoding we want, so I ran under the sqlite shell the
following query against _fossil :
SELECT quote(cast(name as blob)) FROM global_config where name like 'repo:%'
I got X'[...] 6E 74 E9 65 [...]'
(the [..
If you are using Fossil on windows with a non-ASCII character set, and
especially if you are having trouble, please consider using the windows-i18n
branch build that can be downloaded from
http://www.fossil-scm.org/download/fossil-w32-20110513142012.zip
Getting command-line programs to work co
On Fri, May 13, 2011 at 3:56 AM, Benoit Mortgat wrote:
> I just tried to rebuild all my fossil repositories with “fossil all
> rebuild” and I got this error message on one of them (not on the others):
>
I'm thinking that somehow the original MBCS name, rather than the UTF8 name,
for the database
I just tried to rebuild all my fossil repositories with “fossil all rebuild”
and I got this error message on one of them (not on the others):
fossil.exe: SQLITE_ERROR: no such table: main.delta
fossil.exe: no such table: main.delta
CREATE INDEX IF NOT EXISTS delta_i1 ON delta(srcid);
CREATE TABLE
14 matches
Mail list logo
