Re: [fossil-users] Fossil version 1.25 scheduled.
New feature of getting diff by clicling graph in timeline doesn't seem to work on IE8. - Original Message - From: Richard Hipp Sent: 12/01/12 02:46 AM To: fossil-users Subject: [fossil-users] Fossil version 1.25 scheduled. 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 mailing list, or file a ticket. We want 1.25 to be a good release, but we need your help in testing in order to accomplish that. FWIW, we do eat our own dogfood. The Fossil executable that runs the Fossil website gets updated to the tip of trunk roughly every day. The same executable also runs http://www.sqlite.org/ and several other websites. And all of my personal machines (linux, mac, and windows) are running the very latest Fossil code. If there were serious problems with the latest Fossil code, I would be doomed. You can trust that the tip of trunk is reasonably stable. Nevertheless, I'm sure if hundreds of you start testing the latest code, some of you will run across various minor issues, issues that we would prefer to fix prior to 1.25 instead of after. Therefore, do please test. Thanks. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Trunk not buildable with MSVC 6.0 (was: Fossil version 1.25 scheduled.)
On Fri, 30 Nov 2012 16:16:01 -0500 Richard Hipp wrote: > 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 > mailing list, or file a ticket. We want 1.25 to be a good release, > but we need your help in testing in order to accomplish that. Not buildable by MSVC 6.0 compiler as it started do depend on certain wide-character string functions from newer versions of MSVC runtime. After I've added two trivial workarounds to win\include\dirent.h and src\cgi.c to make them compile, I've finally arrived at these complaints from the linker: LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported rebuild.obj : error LNK2001: unresolved external symbol _wcsnlen vfile.obj : error LNK2001: unresolved external symbol _wcsnlen rebuild.obj : error LNK2001: unresolved external symbol _wcsncpy_s vfile.obj : error LNK2001: unresolved external symbol _wcsncpy_s The first two warnings are of unknown importance, but the error messages that follow indicate two unresolved externals: wcsnlen and wcsncpy_s. I'm not sure if this worth fixing or not. It seems that official Win32 builds are done using MinGW, and while it links against the same old msvcrt.dll as MSVC 6.0 does it suppsedly provides its own implementations of those missing functions and hence official Win32 builds will supposedly remain as much portable as before the new dependencies have been introduced. I've attached the patch which fixes dirent.h and cgi.c in case someone will find it useful. Index: src/cgi.c == --- src/cgi.c +++ src/cgi.c @@ -21,10 +21,11 @@ ** formatting function and its cousins, and routines to encode and ** decode strings in HTML or HTTP. */ #include "config.h" #ifdef _WIN32 +# include # include #else # include # include # include Index: win/include/dirent.h == --- win/include/dirent.h +++ win/include/dirent.h @@ -105,10 +105,18 @@ #include /* Windows 8 wide-character string functions */ #if (_WIN32_WINNT >= 0x0602) # include +#endif + +/* + * errno_t is Microsoft-ism, MSVC 6.0 does not define it, + * MSVC 8.0 defines it as int, and that's what the standard says. + */ +#ifndef errno_t +typedef int errno_t; #endif /* Entries missing from MSVC 6.0 */ #if !defined(FILE_ATTRIBUTE_DEVICE) # define FILE_ATTRIBUTE_DEVICE 0x40 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.25 scheduled.
Please add the latest Microsoft Office formats to the supported types. ".xlsx", "docx", "pptx" Thanks On Sat, Dec 1, 2012 at 5:35 AM, Richard Hipp wrote: >> On Sat, Dec 1, 2012 at 4:03 AM, Richard Hipp wrote: >> > I wonder if it should be even more restrictive - and only deliver static >> > content that ends in some well-known subset of suffices: *.html, *.htm, >> > *.jpg, *.jpeg, *.gif, *,png, *.txt, *.css, *.js >> >> I think this would be too restrictive. > > > I changed it so that it will only serve files with one of the 187 different > suffixes for which Fossil is able to guess the mimetype. (See > http://www.fossil-scm.org/fossil/artifact/734e4bf7a6ffc5?ln=97-283) None of > *.fossil, *.fossil-journal, *.fossil-wal, and *.fossil-shm are on that list. -- Clive Hayward ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.25 scheduled.
2012/11/30 Richard Hipp > 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 mailing > list, or file a ticket. We want 1.25 to be a good release, but we need > your help in testing in order to accomplish that. > > FWIW, we do eat our own dogfood. The Fossil executable that runs the > Fossil website gets updated to the tip of trunk roughly every day. The > same executable also runs http://www.sqlite.org/ and several other > websites. And all of my personal machines (linux, mac, and windows) are > running the very latest Fossil code. If there were serious problems with > the latest Fossil code, I would be doomed. You can trust that the tip of > trunk is reasonably stable. Nevertheless, I'm sure if hundreds of you > start testing the latest code, some of you will run across various minor > issues, issues that we would prefer to fix prior to 1.25 instead of after. > Therefore, do please test. Thanks. I have been testing the latest trunk on FreeBSD (so far far no problem spotted) thank you very much, I am a big user of fossil on FreeBSD and really happy with it :) I haven't followed the developpement recently, but was hopping a markdown integration for 1.25 given that a branch for markdown integration has been created month ago. So sorry to bother you again with this, but is there any status for this particular thing? regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.25 scheduled.
On Sat, Dec 1, 2012 at 7:44 AM, Dmitry Chestnykh wrote: > On Sat, Dec 1, 2012 at 4:03 AM, Richard Hipp wrote: > > I wonder if it should be even more restrictive - and only deliver static > > content that ends in some well-known subset of suffices: *.html, *.htm, > > *.jpg, *.jpeg, *.gif, *,png, *.txt, *.css, *.js > > I think this would be too restrictive. > I changed it so that it will only serve files with one of the 187 different suffixes for which Fossil is able to guess the mimetype. (See http://www.fossil-scm.org/fossil/artifact/734e4bf7a6ffc5?ln=97-283) None of *.fossil, *.fossil-journal, *.fossil-wal, and *.fossil-shm are on that list. Other anti-mischief rules: (1) The pathname may only contain ASCII alphanumerics, "_", "/", "-", and "." (2) The pathname may not contain "/-" (3) Any "." in the pathname must be surrounded on both sides by alphanumerics. (4) The pathname may not contain ".fossil" Notice that these rules prevent serving any file whose name begins with "." or "-", prevent the serving of files ending in suffixes like ".off" or ".bu", and prevent things like "/../" in pathnames, etc. > > On a related note, I think you should consider making the previous > behaviour (not serving static files) the default one, and serve static > files only when --static-files or similar flag is supplied. I'm > worried that this change may be surprising to some people who > currently may store sensitive information along with their > repositories. When they upgrade to the new version, suddenly their > files become exposed to the world. > The "fossil ui" command already does this. I'll consider it also for "fossil server". I don't guess I've mentioned (needs to be added to the changelog) that "fossil http" follows the same rules as "fossil server" and will serve static content now. > > -- > Dmitry Chestnykh > http://www.codingrobots.com > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.25 scheduled.
Dmitry Chestnykh decía, en el mensaje "Re: [fossil-users] Fossil version 1.25 scheduled." del Sábado, 01 de Diciembre de 2012 09:44:27: > On a related note, I think you should consider making the previous > behaviour (not serving static files) the default one, and serve static > files only when --static-files or similar flag is supplied. I'm > worried that this change may be surprising to some people who > currently may store sensitive information along with their > repositories. When they upgrade to the new version, suddenly their > files become exposed to the world. Or when a hosting site updates Fossil (Chisel comes to mind). Proposal seconded. -- o-=< Marcelo >=-o ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Error opening a new repository across Windows shares
Le 2012-11-30 à 13:19, Carson Chittom a écrit :
> 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:. Here's the output:
>
> -=-=-BEGIN-=-=-
> H:\>fossil new "C:\Documents and Settings\carson\Repositories\work.fossil"
> project-id: 7c3c5549cdb9e5b77c3c6ee3631c3df829d464fe
> server-id: 97eb47389e0ccbb864ebbf8ea2893b85e89478a0
> admin-user: carson (initial password is "1bba17")
>
> H:\>fossil open "C:\Documents and Settings\carson\Repositories\work.fossil"
> fossil: SQLITE_ERROR: no such table: vvar
> fossil: no such table: vvar
> REPLACE INTO vvar(name,value) VALUES('repository','C:\Documents and
> Settings\carson\Repositories\work.fossil')
>
> If you have recently updated your fossil executable, you might
> need to run "fossil all rebuild" to bring the repository
> schemas up to date.
> -=-=-END-=-=-
>
> Having the files and the repository on the same drive works perfectly,
> whether the drive is local or shared.
Try to work from a subdir inside H:, fossil doesn't like checkout on the root
of a drive. (I don't know in windows, but in OpenBSD and Linux, I had some
issues)
Regards
--
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.25 scheduled.
On Sat, Dec 1, 2012 at 4:03 AM, Richard Hipp wrote: > I wonder if it should be even more restrictive - and only deliver static > content that ends in some well-known subset of suffices: *.html, *.htm, > *.jpg, *.jpeg, *.gif, *,png, *.txt, *.css, *.js I think this would be too restrictive. On a related note, I think you should consider making the previous behaviour (not serving static files) the default one, and serve static files only when --static-files or similar flag is supplied. I'm worried that this change may be surprising to some people who currently may store sensitive information along with their repositories. When they upgrade to the new version, suddenly their files become exposed to the world. -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] filename contains illegal characters
On Sat, 01 Dec, Richard Hipp wrote: > On Sat, Dec 1, 2012 at 4:02 AM, Stefan Bellon > wrote: > > > That's the part I am interested in and I think this should go into > > trunk. > > Added to trunk here: http://www.fossil-scm.org/fossil/info/647bb7b79f Silly me, I just looked at the comment and not the code. Now I'm a happy bunny. :-) Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] filename contains illegal characters
2012/12/1 Stefan Bellon : > sbellon@slim$ fossil status | egrep "(checkout|tags)" > checkout: 99ab9fb47cfb20106564012b7678ca5d579060af 2012-12-01 04:49:38 UTC > tags: trunk > sbellon@slim$ grep "not contain any of these characters" src/file.c > ** * Does not contain any of these characters in the path: "\*[]?" Comment was not updated accordingly. Done now. Thanks! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] filename contains illegal characters
On Sat, Dec 1, 2012 at 4:02 AM, Stefan Bellon wrote: > ** * Does not contain any of these characters in the path: "\*[]?" > > That's the part I am interested in and I think this should go into > trunk. > Added to trunk here: http://www.fossil-scm.org/fossil/info/647bb7b79f -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] filename contains illegal characters
On Sat, 01 Dec, Jan Nijtmans wrote: > I agree with Richard on this. The most important part of the patch is > already on trunk now: allowing '[', ']', '"', '*' and '?' in > filenames. Really? That's the part I am interested in, but I do not see that merged into trunk: sbellon@slim$ fossil status | egrep "(checkout|tags)" checkout: 99ab9fb47cfb20106564012b7678ca5d579060af 2012-12-01 04:49:38 UTC tags: trunk sbellon@slim$ grep "not contain any of these characters" src/file.c ** * Does not contain any of these characters in the path: "\*[]?" That's the part I am interested in and I think this should go into trunk. It makes the code even simpler and not more complex because it removes an exceptional case which is questionable anyway. Regarding the Unicode part of the patch, I agree that this may need some further attention. > The added value of the remaining part is minimal: It would > make the win32 build of fossil do the same as the cygwin build of > fossil. So, you have the functionality already: Just build fossil.exe > for cygwin, it does exactly the same. For some reasons, cygwin is no option here. > That's not sufficient excuse to rush it into 1.25. And missing is > still a test-case description of exactly what is the added value: > What can you do with the changed version what cannot be > done with the trunk version. Well ... having filenames with [ ] " * and ? in the repository and in checkouts if the underlying OS supports it. Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] filename contains illegal characters
2012/12/1 Richard Hipp : >> I would very much like to see this going into the upcoming 1.25 >> release. Is it scheduled to get merged back into trunk? > > > No. This adds complication to a code base that is complicated enough > already. It is vitally important to keep Fossil as simple as possible, in > order to promote reliability and longevity. There are no plans to merge this > branch. I agree with Richard on this. The most important part of the patch is already on trunk now: allowing '[', ']', '"', '*' and '?' in filenames. The added value of the remaining part is minimal: It would make the win32 build of fossil do the same as the cygwin build of fossil. So, you have the functionality already: Just build fossil.exe for cygwin, it does exactly the same. That's not sufficient excuse to rush it into 1.25. And missing is still a test-case description of exactly what is the added value: What can you do with the changed version what cannot be done with the trunk version. Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
