On Thu, 29 Nov 2012 21:19:24 -0300, Richie Adler
richiead...@gmail.com wrote:
Thanks for the tip, but it's much more involved than simply fossil
add *.html.
Peter's solution is much more involved but compiling your own fossil
executable is acceptable?!
It's just that if possible, I'd rather
2012/11/30 Gilles gilles.gana...@free.fr:
1. BTW, if the MinGW version offers better support for shell use, why
is the Windows binary compiled with MSVC?
The Windows binary is compiled with MinGW, only the commandline
parser is replaced, in order to fix bugs like [13b7388964], [490b6c2edd]
On Fri, 30 Nov 2012 07:03:13 -0500, Richard Hipp
d...@sqlite.org wrote:
That has been fixed. The zlib sources are now included with the Fossil
source code. So if you build from one of the latest Fossil version (not
the ones on the Download page - they are too old - but rather a tree you
get
On Fri, Nov 30, 2012 at 7:09 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Gilles gilles.gana...@free.fr:
1. BTW, if the MinGW version offers better support for shell use, why
is the Windows binary compiled with MSVC?
The Windows binary is compiled with MinGW, only the
On Fri, Nov 30, 2012 at 7:12 AM, Gilles gilles.gana...@free.fr wrote:
On Fri, 30 Nov 2012 07:03:13 -0500, Richard Hipp
d...@sqlite.org wrote:
That has been fixed. The zlib sources are now included with the Fossil
source code. So if you build from one of the latest Fossil version (not
the
2012/11/30 Richard Hipp d...@sqlite.org:
That replacement command-line parser is not used on MinGW. Notice the
!defined(__MINGW__) on this line:
http://www.fossil-scm.org/fossil/artifact/a6c2200ac42a?ln=493
In 1.24, this !define wasn't there yet. Since the introduction of
this on trunk,
On Fri, Nov 30, 2012 at 7:20 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Richard Hipp d...@sqlite.org:
That replacement command-line parser is not used on MinGW. Notice the
!defined(__MINGW__) on this line:
http://www.fossil-scm.org/fossil/artifact/a6c2200ac42a?ln=493
On Fri, 30 Nov 2012 13:09:44 +0100, Jan Nijtmans
jan.nijtm...@gmail.com wrote:
The Windows binary is compiled with MinGW, only the commandline
parser is replaced, in order to fix bugs like [13b7388964], [490b6c2edd]
[cadc9aa78f], [d22946aa0c], all related to not using utf-8 on
Windows. This parser
2012/11/30 Richard Hipp d...@sqlite.org:
In 1.24, this !define wasn't there yet. Since the introduction of
this on trunk, the mentioned utf-8 bugs were re-introduced.
The !defined(__MINGW__) was introduced in order to fix this bug:
2012/11/30 Jan Nijtmans jan.nijtm...@gmail.com:
Would switching the default build from MinGW to MinGW-w64
be an option?
I tested the command-line expansion feature from MinGW-w64.
It works! See [b1036fe5bf]. Should work on MSVC as well,
but still untested. Doesn't work on MinGW, because they
Here: [http://fossil-scm.org/index.html/doc/trunk/www/build.wiki] On
section 2.0 Compiling point 8-c:
Documentation say to use Makefile.mingw for Cygwin, but in fact, Cygwin
don't need to use Makefile.mingw, Under Cygwin, the normal Unix way will
work:
e.g.: ./configure make make install
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
I'd suggest -f like cvs rm uses.
obviously everybody seems to have his/her own preference how to
handle this. so only a fraction of users will be happy in the end it
seems. --
2012/11/30 Martin Gagnon eme...@gmail.com:
Here: [http://fossil-scm.org/index.html/doc/trunk/www/build.wiki] On section
2.0 Compiling point 8-c:
Documentation say to use Makefile.mingw for Cygwin, but in fact, Cygwin
don't need to use Makefile.mingw, Under Cygwin, the normal Unix way will
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin c...@apotheon.net wrote:
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
I'd suggest -f like cvs rm uses.
obviously everybody seems to have his/her own preference how to
handle
On Fri, Nov 30, 2012 at 8:32 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Jan Nijtmans jan.nijtm...@gmail.com:
Would switching the default build from MinGW to MinGW-w64
be an option?
I tested the command-line expansion feature from MinGW-w64.
It works! See [b1036fe5bf]. Should
Le 2012-11-30 à 09:40, Jan Nijtmans jan.nijtm...@gmail.com a écrit :
2012/11/30 Martin Gagnon eme...@gmail.com:
Here: [http://fossil-scm.org/index.html/doc/trunk/www/build.wiki] On section
2.0 Compiling point 8-c:
Documentation say to use Makefile.mingw for Cygwin, but in fact, Cygwin
2012/11/30 Richard Hipp d...@sqlite.org:
The changes in the cmdline-expansion branch break the build for mingw32.
Mingw32 does not recognize the -municode option. We have to continue to
support Mingw32 - we cannot force everybody to upgrade to mingw64.
Could some fallback option to built-in
On Fri, Nov 30, 2012 at 11:02 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Richard Hipp d...@sqlite.org:
The changes in the cmdline-expansion branch break the build for mingw32.
Mingw32 does not recognize the -municode option. We have to continue to
support Mingw32 - we cannot
2012/11/30 Richard Hipp d...@sqlite.org:
Can you suggest makefile changes to make this happen?
Done in [2459ee7b71]. Biggest advantage: the
parse_windows_command_line() is not necessary
any more.
Regards,
Jan Nijtmans
___
fossil-users mailing
On Fri, Nov 30, 2012 at 11:45 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Richard Hipp d...@sqlite.org:
Can you suggest makefile changes to make this happen?
Done in [2459ee7b71]. Biggest advantage: the
parse_windows_command_line() is not necessary
any more.
I am unable to
2012/11/30 Richard Hipp d...@sqlite.org:
I am unable to come up with a test case that the trunk does incorrectly that
would work correctly in the cmdline-expansion branch. Can you suggest a
reasonable test case?
For MinGW, the cmdline-expansion does the same as trunk. However,
it has the
On Fri, Nov 30, 2012 at 12:06 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2012/11/30 Richard Hipp d...@sqlite.org:
I am unable to come up with a test case that the trunk does incorrectly
that
would work correctly in the cmdline-expansion branch. Can you suggest a
reasonable test case?
Weighing in on this, finally:
It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?
And is it not something that fossil revert could undo?
I don't mind avoiding the
2012/11/30 Richard Hipp d...@sqlite.org:
2012/11/30 Richard Hipp d...@sqlite.org:
I am unable to come up with a test case that the trunk does incorrectly
that
would work correctly in the cmdline-expansion branch. Can you suggest a
reasonable test case?
I'll work out an example.
Here it
I have put up a change log for Fossil version 1.25 with a tentative release
date of 2012-12-19
http://www.fossil-scm.org/fossil/doc/trunk/www/changes.wiki
There has been a *lot* of change since 1.24. Please test the trunk version
of Fossil as you are able to. Report any issues to this
Hey,
I know it's only a short-cut for something which we could do
before. But I love this new feature; it's one of those I didn't know
how much I wanted it until I started using it, and now I won't be able
to live without it.
Fantastic feature!
--
Kind regards,
Jan Danielsson
2012/11/30 Richard Hipp d...@sqlite.org:
I have put up a change log for Fossil version 1.25 with a tentative release
date of 2012-12-19
http://www.fossil-scm.org/fossil/doc/trunk/www/changes.wiki
I am reading in the ChangeLog:
Disallow invalid UTF8 characters (such as overlength
On Tue, 27 Nov, Jan Nijtmans wrote:
This version allows all characters in filenames that
are permissible on UNIX, except '\'. And those files
can be checked out using Cygwin and Windows as
well, using Cygwin's solution: In the file system
translate those characters to 'safe' characters in
On Fri, Nov 30, 2012 at 5:09 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
Regarding this change:
- Enhance the fossil server DIRECTORY command to serve static
content files contained in DIRECTORY.
It now allows downloading the repo itself.
Thanks for noticing this huge security
Hi!
I discovered Fossil recently and just joined the community.
Here: http://www.fossil-scm.org/index.html/tktnew, I see Important
Note: Tickets are for actual bugs only, where 'bug' is defined to be a
case where the program gets the wrong answer. Feature requests,
documentation typos, and other
I'm using fossil 1.24 (binary downloaded from fossil-scm.org) on Windows
XP. H: is a shared drive from our server, and C: is the local drive.
I'm trying to have the files stored on H:\ but the repository file be on
C:. Creating the repository works, but I get an error when I try to open
it on H:.
31 matches
Mail list logo
