2014-11-25 16:33 GMT+01:00 Stefan Bellon:
If files checked in have CR+LF line endings, then they are correctly
put into a local working copy, but when using fossil cat or fossil
finfo -p to retrieve the file (via stdout redirection), then the CR
gets duplicated, so line endings are no longer
2014-11-26 11:13 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com:
See:
http://www.fossil-scm.org/index.html/info/f2fc37c063
Thanks for your report!
A related problem on win32:
C:\Users\mefossil cat test/utf16be.txt
�� T h i s f i l e c o n t a i n s u t f - 1 6 b e t e x t .
T h e
On Wed, Nov 26, 2014 at 3:57 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
Fix here:
http://www.fossil-scm.org/index.html/info/156ef9ec06
Looking at the part which fetches the istty...
(this was already there before this change)
static int istty[2] = { -1, -1 };
if(
After many builds working properly, this happens:
C:/Prog/MinGW/bin/mingw32-make -C src/../compat/zlib PREFIX= LOC=-DASMV
-DASMINF OBJA=inffas86.o match.o -f win32/Makefile.gcc libz.a
C:\Prog\MinGW\bin\mingw32-make: invalid option -- A
C:\Prog\MinGW\bin\mingw32-make: invalid option -- M
Usage:
Hi fossilers,
Where can I use the th1 command `query` by default? I'm running plain vanilla
fossil 1.29 on Win7x64, and wanted to create a custom ticket report format that
is not just a plain table. I tried running a sample script:
th1
set seenRow 0
set alwaysPlaintext [info exists plaintext]
2014-11-26 16:38 GMT+01:00 Richie Adler richiead...@gmail.com:
After many builds working properly, this happens:
C:/Prog/MinGW/bin/mingw32-make -C src/../compat/zlib PREFIX= LOC=-DASMV
-DASMINF OBJA=inffas86.o match.o -f win32/Makefile.gcc libz.a
C:\Prog\MinGW\bin\mingw32-make: invalid option
fossil clone http://core.tcl.tk/tcl
kamloops$ mkdir jnkjnk
kamloops$ cd jnkjnk/
kamloops$ ../fossil/fossil clone http://core.tcl.tk/tcl ./myrepo.fsl
Round-trips: 23 Artifacts sent: 0 received: 36622
SQLITE_CORRUPT: database corruption at line 53693 of [4461bf045d]
SQLITE_CORRUPT: statement
I can reproduce. Bisecting now
On Wed, Nov 26, 2014 at 12:58 PM, bch brad.har...@gmail.com wrote:
fossil clone http://core.tcl.tk/tcl
kamloops$ mkdir jnkjnk
kamloops$ cd jnkjnk/
kamloops$ ../fossil/fossil clone http://core.tcl.tk/tcl ./myrepo.fsl
Round-trips: 23 Artifacts sent: 0
On Wed, 26 Nov, Jan Nijtmans wrote:
See:
http://www.fossil-scm.org/index.html/info/f2fc37c063
Thanks for your report!
You're welcome. And: Thanks for the quick fix. :-)
BTW: Is there a release schedule for 1.30?
Greetings,
Stefan
--
Stefan Bellon
Problem first appears on check-in
https://www.fossil-scm.org/fossil/info/6b2f0b209f9988153cfaf0ac5d5930bfa8d139fe
which is where is changed SQLite to version 3.8.8 alpha. Select any
version of Fossil prior to that and you should be fine. Or substitute
SQLite 3.8.7.2 and recompile and that will
Richard, fyi, I opened ticket: [3ca776a720d628b0238c8e0dcc321cb82827ad40].
-bch
On 11/26/14, Richard Hipp d...@sqlite.org wrote:
Problem first appears on check-in
https://www.fossil-scm.org/fossil/info/6b2f0b209f9988153cfaf0ac5d5930bfa8d139fe
which is where is changed SQLite to version 3.8.8
On Nov 26, 2014, at 11:29 AM, Stephan Beal sgb...@googlemail.com wrote:
That said: Richard is currently working on some extreme new features, and
have no idea whether he is targeting 1.30 or even 1.40 with those:
Is “fossil bundle” my uber-patch feature? :)
On Wed, Nov 26, 2014 at 7:26 PM, bch brad.har...@gmail.com wrote:
Richard, fyi, I opened ticket: [3ca776a720d628b0238c8e0dcc321cb82827ad40].
Just coincidentally (wasn't going for a reproduce here)...
[stephan@host:~/cvs/fossil/fossil/www]$ sqlite3
SQLite header and source version mismatch
The bug is actually in SQLite. And it looks serious. See the value of
eating your own dogfood! Glad we caught this before it was released!
On Wed, Nov 26, 2014 at 1:26 PM, bch brad.har...@gmail.com wrote:
Richard, fyi, I opened ticket: [3ca776a720d628b0238c8e0dcc321cb82827ad40].
-bch
On
On Wed, Nov 26, 2014 at 7:33 PM, Warren Young w...@etr-usa.com wrote:
On Nov 26, 2014, at 11:29 AM, Stephan Beal sgb...@googlemail.com wrote:
That said: Richard is currently working on some extreme new features,
and have no idea whether he is targeting 1.30 or even 1.40 with those:
Is
On Nov 26, 2014, at 12:14 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Nov 26, 2014 at 7:33 PM, Warren Young w...@etr-usa.com wrote:
On Nov 26, 2014, at 11:29 AM, Stephan Beal sgb...@googlemail.com wrote:
That said: Richard is currently working on some extreme new features, and
On Nov 26, 2014, at 3:07 PM, Ron W ronw.m...@gmail.com wrote:
On Wed, Nov 26, 2014 at 4:49 PM, Warren Young w...@etr-usa.com wrote:
Awesome. That will remove Git’s relative advantage of pull requests, while
making it as easy to use as Subversion.
Pull requests are just a notification
Hello,
I received an e-mail apparently sent to the mailing list which for some
reason doesn't show up in the archives on the web. That's the one I was
replying to - maybe it didn't get through due to the attached script
(batch file for Windows)…
Anyway, based on that very helpful input I
If you have been using the latest trunk versions of Fossil, you should:
(1) Recompile with the very latests
(2) Check all of your repositories for possible corruption. You can do
this easily using the command:
fossil all dbstat --db-check
If you find a repository that gives errors about
Is this on version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC?
- Original Message -
From: Richard Hipp
To: Fossil SCM user's discussion
Sent: Wednesday, November 26, 2014 6:40 PM
Subject: [fossil-users] Check your repos! Was: clone/sqlite error
If you have been using the
Thus said Richard Hipp on Wed, 26 Nov 2014 18:40:19 -0500:
If you find a repository that gives errors about an incorrect fragment
count, then fix them using:
Thanks, apparently my Fossil fossil had an incorrect fragment count, no
others.
It now reports ok.
Andy
--
TAI64 timestamp:
On Wed, Nov 26, 2014 at 6:53 PM, jose isaias cabrera
jic...@cinops.xerox.com wrote:
Is this on version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC?
No. This only applies if you are downloading the latest source code from
trunk and compiling it yourself, and have done so in the past couple of
Perfect! thanks.
- Original Message -
From: Richard Hipp
To: Fossil SCM user's discussion
Sent: Wednesday, November 26, 2014 6:56 PM
Subject: Re: [fossil-users] Check your repos! Was: clone/sqlite error
On Wed, Nov 26, 2014 at 6:53 PM, jose isaias cabrera
On 11/26/14, Richard Hipp d...@sqlite.org wrote:
If you have been using the latest trunk versions of Fossil, you should:
(1) Recompile with the very latests
(2) Check all of your repositories for possible corruption. You can do
this easily using the command:
fossil all dbstat
On Wed, Nov 26, 2014 at 7:10 PM, bch brad.har...@gmail.com wrote:
On 11/26/14, Richard Hipp d...@sqlite.org wrote:
If you find a repository that gives errors about an incorrect fragment
count,
Is this the error you're speaking of:
database-check:*** in database main ***
I had 3 affected repos, according to the stats. I ran the vacuum on them,
and they're fixed, again, according to the stats.
On Nov 26, 2014 5:09 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Nov 26, 2014 at 7:10 PM, bch brad.har...@gmail.com wrote:
On 11/26/14, Richard Hipp d...@sqlite.org
On Thu, Nov 27, 2014 at 12:56 AM, Richard Hipp d...@sqlite.org wrote:
No. This only applies if you are downloading the latest source code from
trunk and compiling it yourself, and have done so in the past couple of
weeks.
And if you (like me) only have a single fossil binary which _is_ that
On Nov 26, 2014 11:18 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Nov 27, 2014 at 12:56 AM, Richard Hipp d...@sqlite.org wrote:
No. This only applies if you are downloading the latest source code
from trunk and compiling it yourself, and have done so in the past couple
of weeks.
28 matches
Mail list logo
