Re: [fossil-users] Who runs Fossil servers on Windows?
Op di 7 aug. 2018 om 18:57 schreef Richard Hipp : > > If you are running a Fossil server on Windows, please share with me > how you set it up. You can respond via private email directly to me > if you like. > > (1) Run using "fossil server" > (2) Run using "fossil winsrv" > (3) Using Apache with CGI > (4) Using Apache with SCGI > (5) Using Nginx with SCGI > (6) Via SSH using some kind of SSHD for Windows > (7) Some other webserver (please specify) > (8) Other (please specify) > > I have the impression that most if not all Fossil servers on Windows > are run using either (1) or (2). If you are using any of the other > approaches, then I especially want to hear from you. In april 2016, I was setting up fossil using a combination of (2) and (7). The IIS frontent was simply used as proxy, forwarding the generic port 80 to the internal port used by the fossil service. That's how I discovered that at that time the --baseurl option didn't work correctly on Windows. I fixed ithat n commit <https://www.fossil-scm.org/index.html/info/6f35075ad72b8608> (and a minor follow-up in the next commit). Since then, everything is working fine. 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] patch: fossil import sha3 marks support
2018-01-16 7:27 GMT+01:00 Dingyuan Wang: > The patch fixes the problem that fossil doesn't recognize sha3 marks > file. <http://www.fossil-scm.org/index.html/info/90b07ed5880a8444> Thanks! Slightly adapted change is now on trunk. 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] tangent vs. wyoung on recent commti
2017-12-18 5:58 GMT+01:00 Ron W: > All I'm suggesting is that the information already being put in the > "rcvfrom" table (that DRH mentioned) also be saved as tags to the commits > they refer to. Therefore, the tags will have the same meaning as the entries > in the existing "rcvfrom" table. Well, I don't think this is even possible, neither does it help accomplishing what you want. Tags can easily forged as well. Another problem: tags, when created in one repository will later synchronized to other repositories (even back to the original one), so I'm really not sure what the value of the information in it really is . I wouldn't go this path. My suggestion would be: try to come up with a patch, which does what you suggest. I don't think it would help anything, but feel free to prove me wrong! 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
Re: [fossil-users] How to disable crlf warning permanently
2017-12-06 10:03 GMT+01:00 Scott Doctor: > > How can I permanently turn off the crlf warning that occurs when I do I do a > commit without having to use the crlf-glob command each time? I do not get > why that warning even exists. Just create a directory ".fossil-settings", and put a file named "crlf-glob" in it. .fossil-settings/crlf-glob Fossil itself has an example: <http://www.fossil-scm.org/index.html/artifact/2da052c2bd7a53c5> Then do fossil add .fossil-settings/crlf-glob fossil commit The warning will be gone once and for all. 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] [PATCH] Improve symlink following offile_wd_isdir()
2017-11-28 0:20 GMT+01:00 : > On Mon, 27 Nov 2017 09:52:19 -0500 > Richard Hipp wrote: >> I am very sorry that I allowed symbolic link support into Fossil in >> the first place. (Symbolic link support was neither designed nor >> written by me - it is contributed code.) I would really like to get >> rid of symbolic link support. Symbolic links seem out-of-place in a >> version control system. As implemented, symbolic links are a point of >> confusion which (as far as I can see) adds no useful capabilities. > > Are you referring to symlinks inside a working directory, or Fossil's > ability to "follow" them? If so have a survey of users, or a > disabled-by-default policy to see if any users need it. This patch has no relation to fossil's symlink support, it's just part of the code to find a suitable temporary directory to write some intermediate file. It's unfortunate it's that complicated, but useful because sometimes the working directory or the current directory is read-only, That's what this code is about. I sometimes use symlink support in fossil, but it shouldn't be fancy at all. When committing a symlink, someone else checking it out should get the same symlink. This - generally - only makes sense when the symlink is relative and points to somewhere else in the working directory. Otherwise - indeed - it doesn't make sense. This is the way that - for example - Subversion handles symlinks, it would be a loss to remove it from fossil. It's just like the 'x' (executable) flag: unfortunate that Windows doesn't handle it the way UNIX does, that's the reason why fossil has to do tricky things That said, symlinks are actually a UNIX-only feature: I don't mind that - on Windows - symlinks check-out as being a file with the link path as content (that's what Subversion does as well ...) 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] Initial empty checkin?
2017-07-17 6:33 GMT+02:00 Damien Sykes-Lindley:
> Hi there,
> Is there a way of removing or preventing the creation of the “initial empty
> checkin”? I personally can’t see any practical uses for that, unless the
> implementation somehow requires it.
> Also, this checkin seems to be automatically sent to trunk. Is there any way
> of renaming this branch, either on the creation of the repository or later
> on?
> Thanks.
> Damien.
Hi Damien,
The patch below modifies Fossil not to create the initial empty
commit. (I always build Fossil with this patch). Everything works
fine without initial empty commit, the reason this was in Fossil is
just historical. Nowadays, there - indeed - is no reason any more
to create an empty initial commit, in my opinion is confuses
more than that it helps anything. Your mail tells me enough
If you want to get rid of an - already created - initial commit, you
can just "purge" it. Normally you need to be careful purging
anything, but in this case it will just work fine. If there already
were follow-up commits, that's no problem: the next commit
will become the new initial commit. If a fossil repository doesn't
have any commits, the first commit you do after that will
become the new initial commit.
Regards,
Jan Nijtmans
Index: src/db.c
==
--- src/db.c
+++ src/db.c
@@ -1997,11 +1997,10 @@
db_begin_transaction();
if( bUseSha1 ){
g.eHashPolicy = HPOLICY_SHA1;
db_set_int("hash-policy", HPOLICY_SHA1, 0);
}
- if( zDate==0 ) zDate = "now";
db_initial_setup(zTemplate, zDate, zDefaultUser);
db_end_transaction(0);
if( zTemplate ) db_detach("settingSrc");
fossil_print("project-id: %s\n", db_get("project-code", 0));
fossil_print("server-id: %s\n", db_get("server-code", 0));
Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -2027,11 +2027,11 @@
db_create_repository(zRepo);
db_open_repository(zRepo);
db_begin_transaction();
g.eHashPolicy = HPOLICY_AUTO;
db_set_int("hash-policy", HPOLICY_AUTO, 0);
-db_initial_setup(0, "now", g.zLogin);
+db_initial_setup(0, 0, g.zLogin);
db_end_transaction(0);
fossil_print("project-id: %s\n", db_get("project-code", 0));
fossil_print("server-id: %s\n", db_get("server-code", 0));
zPassword = db_text(0, "SELECT pw FROM user WHERE login=%Q", g.zLogin);
fossil_print("admin-user: %s (initial password is \"%s\")\n",
___
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] Minor bug with SEARCH command
2017-05-10 15:17 GMT+02:00 Tony Papadimitriou:
> Now, if the same command is given with the –R option to the same repo (e.g.,
> FOSSIL SEA –R repo.fossil) the results are different, and somewhat random.
Indeed! Well, a search without an argument seems little useful, so I would
suggest the following patch below (which was probably intended).
We can easily see that when g.argc==2, the blob_init() will
get a random argument, ist just depends what the option
parsing left there.
Regards,
Jan Nijtmans
--- src/search.c
+++ src/search.c
@@ -597,11 +597,11 @@
}else{
width = -1;
}
db_find_and_open_repository(0, 0);
- if( g.argc<2 ) return;
+ if( g.argc<3 ) return;
blob_init(&pattern, g.argv[2], -1);
for(i=3; ihttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Endless loop in fossil merge (legacy version)
2017-03-26 20:02 GMT+02:00 Francois Vogel: > So it works with fossil-1.33 but not with 1.35. > > Is this problem known? It looks fixed with 2.1 (but it's much slower than > with 1.33): Yes, this was a known bug fixed here: <http://fossil-scm.org/index.html/info/496c0fea3b4d4825 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] import.c: undeclared identifier build files
2017-03-22 15:43 GMT+01:00 jungle Boogie: > import_.c > ..\src\import.c(1385) : error C2143: syntax error : missing ';' before 'type' ... > I see import.c was recently updated. Is this related to the failure above? Yes. Thanks! <http://www.fossil-scm.org/index.html/info/80c94b768982a017> 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] Building Fossil - which commit to use?
2017-03-17 16:08 GMT+01:00 Philip Bennefall: > I am about to build Fossil with Openssl support, and I am wondering what > check-in to use? Should I use the latest commit that is tagged "release" on > trunk, or should I use the tip of "branch-2.1" which seems to have some > later bugfixes? I don't rebuild Fossil often so am looking for as stable a > version as possible. If you want to build with OpenSSL-1.1.0, then I definitely would build with either "trunk" or the tip of "branch-2.1", because of the following bug-fix from Debian: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847556#10> If you are using Openssl-1.0.2, then this doesn't matter, whatever version is fine. My recommendation would be, just take the top of the "trunk" (as Richard recommended too), it's as stable as it can be ;-) 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] Fossil can not import its own git export
2017-03-15 14:08 GMT+01:00 Jan Nijtmans:
> Please report those things on the SQLite mailing list,
> so it can be properly reviewed and applied upstream.
of course, this should be Fossil mailing list ...
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] Fossil can not import its own git export
2017-03-10 23:41 GMT+01:00 Martin Gagnon: > It seems to be a problem with a weird filename (with a newline in it), > added in this checkin: > http://fossil-scm.org/index.html/info/ac1af2306b70c537 > I have no clue how to fix that. Looks like Debian has a fix for that: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840251> Osamu Aoki's (the patch author) remark: > These codes are BSD-2-Clause licensed and I agree to copyright > assignment to Hipp, Wyrick & Company, Inc. to any patches submitted to > this ML. > > Please review and consider. @osamu: Please report those things on the SQLite mailing list, so it can be properly reviewed and applied upstream. 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] Support for commonmark markdown in fossil
2017-03-14 16:27 GMT+01:00 Mark Janssen:
> Or in patch form:
...
http://fossil-scm.org/index.html/info/dd41f85acf57290a
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
[fossil-users] Fossil 2.0 for win64 [Was: Fossil Version 2.0]
2017-03-03 14:45 GMT+01:00 Richard Hipp: > Fossil version 2.0 is now available on the Fossil website > (https://www.fossil-scm.org/download.html) and its mirrors. > > Fossil 2.0 is 100% backwards compatible with Fossil 1.x. Do no worry > about the change in the first digit. For anyone interested in a 64-bit Windows build, this can be found here: <https://sourceforge.net/projects/cyqlite/files/fossil/> 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] Linux binary downloads
2017-02-20 16:42 GMT+01:00 Richard Hipp: > On 2/20/17, sky5w...@gmail.com wrote: >> Any chance to get the Windows binary as x64 also? You can find my win64 build here: https://sourceforge.net/projects/cyqlite/files/fossil/ It is marked 1.37.1, because it is built with openssl 1.1.0e and SQLite 3.17.0, and it has a few more fixes discovered just after 1.37. (see the 1.37 branch in the fossil repository) > The problem with that (for me at least) is that it is difficult to > compile the OpenSSL library using MSVC. OpenSSL really wants to be > compiled with MinGW. And I only have a 32-bit MingGW compiler. So > (for me at least) the choices are 32-bit Windows builds, or 64-bit > builds that lack "https" capabilities. So, what's the problem with the mingw-w64 compiler? Works fine in my environment, and - as far as I know - in any 64-bit windows environment. 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] Git Tag comments
2017-02-13 12:09 GMT+01:00 Roy Marples: > Is the value displayed in the timeline? Yes > I'm also unsure about overloading the meaning of tag value . the ui > indicates it can be set via the command line so could someone be using > it for something else to store in fossil? For some tags, like "color" or "branch" the tag value has meaning in Fossil. But for "sym-" tags, the value currently is not used for anything (other than displaying it in the timeline). Does that answer your question? 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] Git Tag comments
2017-02-13 4:50 GMT+01:00 Roy Marples: > 3 has now been implemented in the roy-export branch. > Turned out to be quite easy. A database rebuild is required though as an > extra field has been added to the tagxref table. Thanks, Roy! I looked at your implementation: cards have to be in alphabetical order, so a "C" tag after a "T" tag will simply not work. But ... tag are allowed to have a "value", which is currently not used in fossil. This would be more logical. Advantage: no schema change is necessary. My attempt implementing this can be found in the "jn-export" branch. Not actually tested with GIT yet. Great work, 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
Re: [fossil-users] Problem with Fossil compilation on Windows
2017-01-21 17:29 GMT+01:00 Richie Adler: >> Jan Nijtmans Thu, 19 Jan 2017 01:57:05 -0800 >> Try: >> C:\Prog\MinGW\msys\1.0\bin\make.exe -e -f win\Makefile.mingw X64=1 >> FOSSIL_ENABLE_JSON=1 > > Sadly, that didn't solve the issue. Same errors. > Did you do a full clean before re-building? If not, the earlier built libz.a will not be built again. 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] Problem with Fossil compilation on Windows
2017-01-19 0:13 GMT+01:00 Richie Adler: > Windows 7 Ultimate 64 bit > gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 5.3.0 > > Running this: > > C:\Prog\MinGW\msys\1.0\bin\make.exe -e -f win\Makefile.mingw clean > SET FOSSIL_ENABLE_JSON=1 > C:\Prog\MinGW\msys\1.0\bin\make.exe -e -f win\Makefile.mingw > > Generates these errors: > > src/../compat/zlib/libz.a(deflate.o):deflate.c:(.text+0x745): undefined > reference to `longest_match' ... Try: C:\Prog\MinGW\msys\1.0\bin\make.exe -e -f win\Makefile.mingw X64=1 FOSSIL_ENABLE_JSON=1 Just have a look at comment line #16 of win\Makefile.mingw, you'll see why. If you want a full 64-bit (with openssl-1.1.0c and more, json too), have a look at: <https://sourceforge.net/projects/cyqlite/files/fossil/> 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] OpenSSL in the source tree
2016-11-02 7:29 GMT+01:00 Joe Mistachkin: > I think using OpenSSL 1.1 will only work on the "openssl-1.1.0" branch. For Windows, that's true. For other platforms, openssl-1.1 works fine in Fossil 1.36 or later. The reason is that dll names were changed in openssl-1.1.0, this needs some build changes. But on other platforms, openssl is 'almost' upwards compatible, at least sufficiently for fossil to work unmodified. > Here are the commands I generally use to get things all working in the > source tree: > > cd compat/zlib && ./configure && make > cd .. > wget -4 https://www.openssl.org/source/openssl-1.0.2j.tar.gz > tar -zxvf openssl-1.0.2j.tar.gz > mv openssl-1.0.2j openssl > cd openssl > ./config --with-zlib-include=../compat/zlib --with-zlib-lib=../compat/zlib > make depend > make > cd ../.. > ./configure --with-zlib=tree --with-openssl=tree > make So, just use openssl-1.1 in the above, and everything should work fine. 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] Errors trying to compile
Op 13 okt. 2016 03:28 schreef "Joe Mistachkin": > Using that makefile with Cygwin is untested, unlikely to work, and unsupported. Yes, it works and is supporter (by me). You need the mingw-w64 cross-compiler package for Cygwin (either the 32-bit or 64-bit one). See the comments at the top of the Makefile how to do that. 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] Infinite loop on merge
2016-09-08 1:32 GMT+02:00 Ross Berteig: > So my testing does not block releasing 1.35.1. > > I have no strong opinion about whether such an update is required, but the > most recent regression does seem like it causes real problems if tripped > over. I agree, but it's not up to me to decide. Upcoming SQLite 3.14.2 might be an additional excuse to do a fossil 1.35.1 release (although I don't think fossil is actually affected by any of the fixed bugs since SQLite 3.13) 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
[fossil-users] Openssl 1.1.0 [Was:Objections to merging stash-fixes branch?]
2016-09-08 5:00 GMT+02:00 Joe Mistachkin: > I think the MSVC makefile needs updating for the OpenSSL 1.1.0 changes > to work. I think it should work fine after my changes, but feel free to fix anything I screwed up ;-) > Also, maybe we should wait for 1.1.0 to mature a bit prior > to migrating Fossil to it? Technically, their 1.0.2 branch is still > listed as "stable" and "supported" (until 2019-12-31). That's your decision (or .. actually Richard's ???) In my view, openssl-1.1.0 has a larger user base than SQLite 1.15, so it should be OK for fossil trunk. I didn't find anything wrong with it so far. (I wouldn't recommend it - yet - as default for the 1.35 branch) 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] Infinite loop on merge
2016-09-07 5:17 GMT+02:00 Joel Bruick: > This is the right fix. It ensures that each commit is only added to the > queue by the recursive SELECT once instead of an exponential number of times > based on how many merge commits it finds along the way, which is what caused > your problem. I don't know why I used UNION ALL there, but it's definitely > wrong. Well, I noticed the lock-up as well, some weeks ago but didn't bother to dig into it because I could do what I wanted to do by merging the other way. Glad that it's fixed now! Thanks! Would this be enough reason to do a quick 1.35.1 release? Two regressions are already found plaguing 1.35 for situations which worked fine in 1.34. Branch "branch-1.35" is ready, the only thing missing there is updating changelog.wiki. 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] [TCLCORE] FYI - tcl core - unintended fork
2016-07-05 16:18 GMT+02:00 Jan Nijtmans: > But there is currently a bug in fossil which shows > a closed fork with an additional arrow going up. Now I don't > have an example any more showing this ;-( Never mind ... found it: <https://www.fossil-scm.org/index.html/info/f16e1a0eab404fcb> 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] [TCLCORE] FYI - tcl core - unintended fork
2016-07-05 15:43 GMT+02:00 Donal K. Fellows: > It's corrected now. Yes, thanks!But there is currently a bug in fossil which shows a closed fork with an additional arrow going up. Now I don't have an example any more showing this ;-( It appears that the fossil bug was introduced with this commit: <http://www.fossil-scm.org/index.html/info/f73411025e8ebec70029> investigating .. This appears to fix the bug, probably not the right fix . but it works. <http://www.fossil-scm.org/index.html/info/a78e51185326b91f> 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] how to report bug in fossil
2016-06-10 10:12 GMT+02:00 Scott Robison: > FYI, my test code here (C++ harness) consisted of passing every possible > four byte buffer to the old function and my new function. My function > identifies the expected number of "strings" as valid UTF-8. I didn't eyeball > each one to make sure the right ones got through, but getting the exact > right number is promising to me. > > Let me know if you see anything horridly wrong with my code. It's 2am... It turns out that your code appears fine, it's just less efficient than mine ;-) There were test-failures but all failures turned out to be errors in the expected test-outcome. I fixed those test-cases now, added more of them, and fixed the invalid_utf8() function in trunk. Now all tests pass with both trunk code and your code. Many thanks, Scott ! Once more, fossil got better than it was! 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] how to report bug in fossil
2016-06-10 9:24 GMT+02:00 Scott Robison: > On Fri, Jun 10, 2016 at 1:15 AM, Jan Nijtmans > wrote: >> >> 2016-06-10 2:01 GMT+02:00 Scott Robison: >> > I just committed >> > a one line fix (with multiple lines of comments to clarify what the code >> > is >> > doing in the tricky part). >> >> Scott, I owe you. Many thanks! You are completely right, this was an >> edge-case not covered for. > > > Glad to be able to get to something before everyone else for a change. :) > > FYI: There is another problem, I think, with some invalid 4 byte sequences > being accepted (F4 00 80 80, for example). I'm working on a proposed fix. Yeah... after your fix, the following byte sequence is accepted as valid while really it isn't: \xE0\x80\x80 (discovered by simply running the test suite) So, it's still not correct yet. 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] how to report bug in fossil
2016-06-10 2:01 GMT+02:00 Scott Robison:
> I just committed
> a one line fix (with multiple lines of comments to clarify what the code is
> doing in the tricky part).
Scott, I owe you. Many thanks! You are completely right, this was an
edge-case not covered for.
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] keep-glob
2016-05-23 23:20 GMT+02:00 Ron W: > To my thinking "keep-glob" and "ignore-glob" are 2 different features with > different symantics. So far, I have not had a need to use keep-glob as I > don't use the "fossil clean" command. > > But, I see that the description for ignore=glob says 'files that the "add", > "addremove", "clean", and "extra" commands will ignore'. So, if everything > in the keep-glob is also in the ignore-glob, what does keep-glob do that > ignore-glob doesn't do? The difference can only be seen in verbose mode (-v). Any file matching keep-glob will result in a warning: KEPT file not removed (due to --keep or "keep-glob") Agreed it's a very thin use-case, thinking about it now ;-) 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] keep-glob
2016-05-23 2:46 GMT+02:00 Andy Goth: > What is the difference between keep-glob and ignore-glob? As far as I > know, stuff in keep-glob shows up in extras and addremove, whereas it > would be excluded if in ignore-glob. Are there any cases where you'd > want to protect something from cleaning yet want it to show in extras > and addremove? Well, keep-glob was added to fossil on my request. Everything I have put in keep-glob is in ignore-glob too, I cannot imagine any usecase for putting something in keep-glob without putting it in ignore-glob too. > Is there any difference at all between having something in keep-glob > only and having it in both keep-glob and ignore-glob? I don't think so, > but maybe I'm wrong. I think it's wrong to put something in keep-glob without putting it in ignore-glob too. I never do that. So, what's your suggestion? Handle keep-glob in extras and addremove just as in clean? I would support that, it doesn't have to wait for fossil 2.0 if you would ask me. It would mean that I can simplify my ignore-glob setting a bit, indeed a bit more logical. 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] keep-glob
2016-05-22 1:05 GMT+02:00 Andy Goth: > What is keep-glob good for? Does anyone use it in their projects? Or > the -keep option to clean? I use it for protecting the built fossil executable being cleaned. So I can do ".\fossil.exe clean " without the danger that fossil.exe would clean itself while running. It could also be used to protect specific files which don't influence the build (such as long log files) from being cleaned, those files will then typically be in ignore-glob too. Not used very often, but still I prefer to keep it. 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] Fossil 2.0: rethinking extras, addremove, and clean
2016-05-22 4:03 GMT+02:00 Joe Mistachkin: > Andy Goth wrote: >> My recommendation is to keep the promise made by the current addremove >> documentation. That is to say, make extras and adds be equal. This >> means changing the extras command to also ignore files matched by >> clean-glob: extras = adds = tree - managed - ignore-glob. > I do not recall the exact rationale behind the existing semantics; > however, I'm pretty sure there was a length discussion (or two) on the > mailing list at some point. My recommendation is to remove the clean-glob setting and related functionality altogether. It was a mistake. For the reasons why, see: <https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg11685.html> 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] Fossil build improvements...
2016-02-07 19:12 GMT+01:00 David Macek: > The reason is to reduce unexpected behavior. In MSYS2, we want to build > software as close as > reasonably possible to Linux "originals". I can see that the WIN32/CYGWIN > stuff is there for a > reason, but it's more suited for Fossil as a stand-alone app on otherwise > graphical Windows. Yes, I see. You are using msys2 as a kind of "minimal cygwin". Does that also mean that your fossil.exe depends on msys dll's? If so, I don't think that's suitable for a large public, it will work fine only in an msys2 environment. However, I looked at your patch, and I see the goal behind it. Thanks! >> BROKEN_MINGW_CMDLINE is meant for the original mingw only, for >> mingw-w64 everything's fine. For details, see: >> <http://sourceforge.net/p/mingw/bugs/771/> > > I tried it just now with v1.34 and I need to explicitly define it, otherwise > the build breaks with `undefined reference to `WinMain'` because of the > main/wmain change. It seems that in trunk, it gets defined automatically now. This looks like a missing "-municode" linker option. For details how to create a UNICODE-aware executable with mingw-w64, see: <https://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/> (B.T.W. : defining _UNICODE/UNICODE is not necessary for fossil, because it implicitly uses the wide API everywhere already). This is the only way I know which enables the use of _all_ unicode characters on the command line, not only the ones in the current windows code-page. 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] Fossil build improvements...
2016-02-07 14:12 GMT+01:00 David Macek: > Hmm. So hopefully he's watching the list. Yes, I am watching this list. I always build fossil using win/Makefile.mingw or win/Makefile.mingw.mistachkin, they work fine in the combinations I normally use. My (64-bit mingw-w64) build can be found here: <http://sourceforge.net/projects/cyqlite/files/fossil/> > One of my problems is with the linenoise library. It requires and > possibly other POSIX-only stuff. Is there a way to override it to use > editline/readline? I didn't try to enable lineoise, I just was assuming it wouldn't work on win32. > Slightly off-topic: Is there a chance that some of the `#if defined(_WIN32) > || defined(__CYGWIN__)` stuff can be put under an additional condition? I > disable a bunch of these using a patch, but using a define instead would be > nicer. Well, I'm interested in your patch, and the reason for disabling those parts. I'm not aware of any trouble those sections might cause, but I'm aware of the trouble that might be caused by leaving them out ;-) > Is FOSSIL_ENABLE_MINIZ in Makefile used at all? I get `FOSSIL_ENABLE_MINIZ = > @FOSSIL_ENABLE_MINIZ@` in my Makefile. I don't think using miniz gives any advantage, linking in zlib statically is what I always do. > Is BROKEN_MINGW_CMDLINE supposed to be defined on mingw-w64? It seems to > build and work regardless (both globbing and non-ASCII characters in > filenames), but maybe I'm missing something. BROKEN_MINGW_CMDLINE is meant for the original mingw only, for mingw-w64 everything's fine. For details, see: <http://sourceforge.net/p/mingw/bugs/771/> 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] Windows/MinGW build
2016-01-13 18:08 GMT+01:00 LM: > Jan Nijtmans wrote: >> However, I would recommend to use MinGW-w64, then you >> can use all unicode characters in the command line you like > > A lot of die-hard original MinGW users including myself refuse to use > MinGW-w64 due to licensing related issues. I feel everyone should be > able to use the tools/utilities/compilers they're most comfortable > with. I'm perfectly happy with my own MinGW fork and it does a few > things that MinGW-w64 can't. I'm sure that's true. In my opinion, Fossil builds better with MinGW-w64 than with MinGW because the lack of UNICODE support in MinGW. See: <https://sourceforge.net/p/mingw/bugs/771/> If MinGW would support UNICODE applications (as MSVC and MinGW-w64 do), then those lines in Fossil could be simplified: <http://www.fossil-scm.org/index.html/artifact/5cbae19db27ca153?ln=584-592> Pity for Fossil, this MinGW bug #771 is already open for almost 10 years, and I don't see any progress on it. :-( 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] Windows/MinGW build
2016-01-12 17:41 GMT+01:00 LM: > I did not see the MinGW issues mentioned at > https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c > "fossil extra" seems to work okay. > I'm using MinGW based on gcc 4.9.2, mingwrt-3.20-2, w32api-3.17-2 plus > my own patches and pthreads/C11 threads support. Not seeing any > compiler issues at this point. This MinGW issue was only relevant when using mingwrt-4.x, but there were so many problems with this new version that the developers abandoned it and went back to 3.20. However, I would recommend to use MinGW-w64, then you can use all unicode characters in the command line you like. See: <http://fossil-scm.org/index.html/tktview/edab7bb5c973f41fced6> 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] source code file is considered by fossil to be binary.
2015-11-06 2:12 GMT+01:00 Richard Hipp: > Offending code is here: > https://www.fossil-scm.org/fossil/artifact/10cb5eb292?ln=40-43 > > I guess sky5walk wants that to allow through any characters other than > 0x00 My guess is that the code in doc.c was written when the function looks_like_binary() didn't exist yet. Should be fixed now: <https://www.fossil-scm.org/fossil/info/b51ba29365b93b3f> Whatever definition of BINARY is chosen, I think it should be the same everywhere within fossil. 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
Re: [fossil-users] source code file is considered by fossil to be binary.
2015-11-05 19:37 GMT+01:00 : > Hi, > I am also trapped with this binary file detection for the egregious use of > ascii characters 2 and 6 in my code. :( > > ;// ascii2+sometexthere+ascii6 > ;//sometexthere ;<-- pasting here does not show the prefix and suffix > ascii characters. As far as I know, fossil doesn't use control characters to decide the file is binary, only the null-byte. So I think something else is triggering the binary detection. Too long lines, maybe? 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] Can't build Fossil 1.34 with Tcl 8.5
2015-11-02 23:43 GMT+01:00 Piotr Orzechowski : > Hi, > > I can't build Fossil 1.34 with Tcl 8.5 (8.5.0-2.1) on fully up-to-date > Debian Wheezy 64-bit. > > I configure Fossil with: > > ./configure --prefix=/opt --with-openssl --with-tcl=/usr/lib/tcl8.5 > --with-th1-hooks --json --with-zlib Just add the options --with-tcl-stubs and --with-tcl-private-stubs, then it will work fine. (Don't ask me why this isn't the default when using --with-tcl, I think it should be) 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] Time to release Fossil version 1.34?
2015-10-20 19:51 GMT+02:00 Joe Mistachkin : > Jan Nijtmans wrote: >> >> It turns out that the cause of this problem is the following commit: >> <http://www.fossil-scm.org/index.html/info/9431fec1ea098fea> >> so I backed it out. My local trunk build doesn't show the problem >> any more. >> > > Actually, it appears you backed out two check-ins. The original one and > the follow-up that fixed the timeline issue it had. Yes, that was on purpose. Since the second commit fixed a problem in the first one, only backing out the first would would result in left-over dead code. > I've moved the backout off trunk so the issues that remain, if any, can > be fixed prior to the release. It's up to you (or Richard) to review it. Please don't take too long, it's only a few lines of code. And people are already complaining about this issue. 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] Time to release Fossil version 1.34?
2015-10-20 9:16 GMT+02:00 Marcel Graf : > On Sun, Oct 18, 2015 at 10:38 PM, Joe Mistachkin > wrote: >> There seems to be a timeline issue: >> >> https://system.data.sqlite.org/index.html/timeline?n=50&y=all&v=1 >> >> The [2c6bdf20ea] merge check-in has two entries for each of the modified >> files. > > > The are also duplicate entries in the Changes-section of the Check-In page > https://system.data.sqlite.org/index.html/info/2c6bdf20ea066691, even after > the fix http://fossil-scm.org/index.html/info/22e0427b1048534e to fossil. It turns out that the cause of this problem is the following commit: <http://www.fossil-scm.org/index.html/info/9431fec1ea098fea> so I backed it out. My local trunk build doesn't show the problem any more. 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] Trying to compile fossil with TCL integration
2015-09-03 16:16 GMT+02:00 Warren Young : > I tried building --with-tcl a few days ago on a system that ships Tcl 8.4. > (CentOS 5.) It configured, but it gave a compile error complaining that it > couldn’t find Tcl_Canceled() in th_tcl.c. The reference page for that > function doesn’t say when it was introduced, and Google didn’t turn up > anything, but I got hints that it might have been added in Tcl 8.6. It was introduced in Tcl 8.6, indeed: <http://www.tcl.tk/cgi-bin/tct/tip/285.html> > Can anyone else verify that Tcl 8.4 can still be embedded into Fossil? You should configure with "--with-tcl --with-tcl-stubs --with-tcl-private-stubs". This way (which should be the default IMHO) fossil will use its own Tcl header for compilation (derived from Tcl 8.6.0), and check the actual Tcl version at runtime which. This should still work with Tcl 8.4. 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] Trying to compile fossil with TCL integration
2015-09-02 12:55 GMT+02:00 Remco Schoen :
> I’m trying to compile fossil with TCL integration for some testing with the
> TH1-hooks, but I’m not really getting anywhere. Maybe my test-case for trying
> to determine if the TCL integration is working is flawed and there is a
> better way to determine it.
> Any clues what I’m doing wrong?
You can check whether your fossil is compiled correctly with:
$ fossil version -v
This is fossil version 1.33 [73960e0de5] 2015-08-27 04:39:42 UTC
Compiled on Aug 27 2015 12:22:38 using gcc-4.9.3 (64-bit)
SQLite 3.8.11.1 2015-07-29 20:00:57 cf538e2783
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2d 9 Jul 2015)
TCL (Tcl 8.6.0, loaded TH_OK: 8.6.4)
USE_TCL_STUBS
TCL_PRIVATE_STUBS
UNICODE_COMMAND_LINE
DYNAMIC_BUILD
If you find the line with TCL in there, everything should be OK.
Then, enable it:
fossil set tcl 1
After that, it should work, but not in the test-th-eval command ;-)
You could try "fossil ui" and then go to Admin -> TH1. Typing
the command "tclEval {info tclversion}" from there works.
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] SVN-fs-dump-format-version: 3 will produce unusable blobs
2015-08-26 20:16 GMT+02:00 Baruch Burstein :
> I am sorry it took me so long to get to this. I don't know if it is still
> relevant for you, but I fixed this here:
> http://fossil-scm.org/index.html/info/24048eadf9247452
It will be relevant for someone. Thanks! Glad to know
that the problem is located and corrected.
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] Adding 'undo' support to the 'clean' command...
2015-07-10 12:04 GMT+02:00 Jan Nijtmans : > $ ./fossil clean > WARNING: Deletion of this file will not be undoable via the 'undo' > command because the file is too big. > Remove unmanaged file "abc.x" (a=all/y/N)? y > > Yes, that's exactly how I expect it to work. > > Thanks! >Jan Nijtmans Trying something else: $ mkdir abc $ fossil clean --emptydirs Remove empty directory "abc" (a=all/y/N)? y $ If deletion of files is undoable, how about the deletion of empty directories? Or am I asking too much? ;-) 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] Adding 'undo' support to the 'clean' command...
2015-06-29 18:40 GMT+02:00 Joe Mistachkin: > I've come up with an alternative implementation of this feature that I think > is a bit simpler (see the "enhancedUndo" branch). It avoids making changes > to anything that is unrelated to the goal at hand. I would really > appreciate > feedback. Well, I tested your enhandedUndo branch, adding all the built objects to "ignore-glob" (so I don't lose the build during testing): $ ./fossil extras $ touch abc.x $ ./fossil extras abc.x $ ./fossil clean $ ./fossil undo NEW abc.x Then, with a >10M file: $ ./fossil extras $ cp [some-large file] abc.x $ ./fossil extras abc.x $ ./fossil clean WARNING: Deletion of this file will not be undoable via the 'undo' command because the file is too big. Remove unmanaged file "abc.x" (a=all/y/N)? y Yes, that's exactly how I expect it to work. 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
Re: [fossil-users] fossil serve repolist error
2015-06-28 21:06 GMT+02:00 Remco Schoen : > Finally found some time to test and react. The webserver now “freezes” when > trying to open the repolist, like the request never is closed from the > server side. The process takes 100% CPU then. Even though I'm not familiar with this part of the fossil code, just wanted to let you know that I'm reading this with interest. As soon as this problem is fixed, I would like to cherry-pick the fix, and update the nijtmans/fossil docker image. 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] fossil undo for fossil clean
2015-06-26 21:03 GMT+02:00 Andy Goth : > I was a bit surprised that you explicitly make the -f option inhibit > undo. I would have done otherwise. That makes sense. I wanted there to be an option to inhibit undo, and re-used -f for that. Looking at it now, it's better to inhibit it with -x, not when using -f only. > As for the size limit, you present one option: confirming whether or not > to back up files larger than ten megabytes. A refinement would be to > make this threshold a setting. Yes, eventually that should be a setting. > No conclusions, just getting some thoughts in writing. Will revisit > when I have time. Thanks for your idea, and having a look at the branch. It's certainly not ready yet, but your input can get the branch closer to being finalized. 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] fossil undo for fossil clean
2015-06-26 6:31 GMT+02:00 Andy Goth : > Is there any interest in making fossil clean be an undoable operation? > If fossil revert is undoable, why not fossil clean? I already implemented that, feel free to experiment with it: <http://fossil-scm.org/index.html/timeline?r=undo-clean> The problem is that this function might make the _FOSSIL_/.fslckout file much much bigger, e.g. when a lot of built files are cleaned. This can be improved by handling the following files differently: 1) files matching "glob-ignore", those will be removed without the possibility to recover. 2) files > 10M (is this a good value?), those will be prompted for, before removing them forever. I never really needed that, therefore I didn't do enough with it to thrust it for 100%. But if it's usefull to you, I'm happy about that. Regard, 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] Issue with cloning a repo
2015-06-17 15:56 GMT+02:00 Jacek Cała : > Hi, > > Please find below some details about the software running in my container: > > - fossil version -v says: > This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC > Compiled on Jun 10 2015 22:28:08 using gcc-4.6.3 (32-bit) > SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1 > Schema version 2015-01-24 > zlib 1.2.3.4, loaded 1.2.3.4 > SSL (OpenSSL 1.0.1 14 Mar 2012) > UNICODE_COMMAND_LINE > > It's been downloaded from the fossil download web page as the precompiled > binary for linux Yes, that's what I thought. When compiling fossil using the option -static, gcc gives the following warning: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking well, your docker container doesn't have the necessary 32-bit shared libraries ... There are two solutions: - compile fossil as 64-bit linux executable. - obtain the missing shared library (I have no idea which one, or where to get it ) You can use my container, which contains a functioning docker build of fossil: <https://registry.hub.docker.com/u/nijtmans/fossil/> 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] Issue with cloning a repo
2015-06-16 17:44 GMT+02:00 Jacek Cała : > Hi, > > I'm running fossil 1.33 in a docker container and found an issue when > cloning my repo. If I run it like: > > $ fossil clone http://USERNAME@SERVERNAME/REPONAME repo.fossil What does "fossil version -v" say? Or "file fossil"? Is the fossil binary self-compiled or obtained elsewhere? Is it a 32-bit or 64-bit binary, is it statically linked or not? Answers to those questions might give a hint on what's happening here. 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] Version 1.33 win64
2015-05-25 11:34 GMT+02:00 Jan Nijtmans: > For anyone interested, I built fossil 1.33 especially > for win64, it's available here: > > <https://sourceforge.net/projects/cyqlite/files/fossil/> > > This binary is compiled with latest MinGW-w64 compiler, > and with json support, ssl support, tcl support, th1-docs > and th1-hooks support and with legacy-mv-rm support. > (If you don't know what this all means, you > probably don't need it but it won't hurt either) Minor update. Since openssl 1.0.2b is just released with a few security fixes, and a fix for the crash in the /reports web-page was developed <http://fossil-scm.org/index.html/info/8184f39d803f9ad6> I just rebuilt the win64 fossil binary with those 2 changes. It can be downloaded from the same place: <https://sourceforge.net/projects/cyqlite/files/fossil/> 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] please compile official fossil builds with https support
2015-06-11 17:52 GMT+02:00 Richard Hipp : > On 6/11/15, Michal Suchanek wrote: >> >> When you link dynamically with libssl then your distribution is >> responsible for updating libssl in response to libssl vulnerabilities. >> > > Yes. On the other hand, Fossil only uses libssl on the client side. > And client-side SSL has far fewer and less severe vulnerabilities than > server-side. So even if vulnerabilities are discovered and you do not > update, you are probably still ok. There are two more practical problems why fossil must link with static libssl for the Linux downloadable executable. 1) A dynamic libssl will - in turn - be linked with a dynamic libz. Because fossil includes a static libz as well, this opens the hole of possible symbol conflicts. As long as the libz versions are close enough (I think >=1.2.5 is OK) this wouldn't cause problems, but internal changes in future libz versions could easily break that. Conclusion: if fossil links with dynamic libssl, it should link with dynamic libz as well. 2) Different linux distributions use a different library name for libssl/libcrypto. e.g. Fedora: libssl.so.10 -> libssl.so.1.0.2 Ubuntu: libssl.so.1 -> libssl.so.1.0.1 So it is impossible to build a fossil binary with works on both Fedora and Ubuntu if libssl is linked dynamically. I don't see any other solution than linking libssl statically. Of course, Fedora and Ubuntu have the option to provide their own fossil binary, which links with both libz and libssl dynamically. But such a build will be Fedora/Ubuntu-specific, and is not guaranteed to work on any other Linux distribution. I don't expect sqlite.org to provide downloads for each and every Linux distribution . 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] "mv --hard" bug!
2015-06-08 14:26 GMT+02:00 Tony Papadimitriou : > The repo root is one directory above this one. > As you can see the ...so/so... in the path shows that the mv on the disk was > attempted with a full relative path (from repo root) instead of the path > relative to where I was at the moment (inside so subdirectory). > > My fossil is: > This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC > Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit) > SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1 > Schema version 2015-01-24 > zlib 1.2.8, loaded 1.2.8 > SSL (OpenSSL 1.0.2a 19 Mar 2015) > UNICODE_COMMAND_LINE This problem was fixed the very next day, 2015-05-29 17:14:59: <http://fossil-scm.org/index.html/info/c56a387d47e5efde> 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] relative vs full path for external diff command
2015-06-04 19:22 GMT+02:00 Joe Mistachkin: > First, I read the code involved very carefully and experimented with it here > locally. > > I wanted to agree with the change when I thought it was only impacting the > file names > that were shown to the user; however, it actually changes the arguments > passed to the > child process (i.e. which may be reconfigured by the user). This is > technically a > breaking change because some tools may not be able to handle relative paths > (i.e. they > may not preserve the current directory correctly). Would you accept the patch if the use of relative paths was for win32 and cygwin only? External diff tools which handle relative paths the way you describe don't exist on win32/cygwin. This allows cygwin fossil to use a win32 diff tool (like winmerge) or a win32 fossil to use a cygwin diff tool, no matter if the current directory is c:\Users\foo (win32), /cygdrive/c/Users/foo (cygwin) or /c/Users/foo (msys). See: <http://www.fossil-scm.org/index.html/info/c9f3266836f1f7fe> 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
Re: [fossil-users] relative vs full path for external diff command
2015-06-03 17:42 GMT+02:00 Ron W : > On Wed, Jun 3, 2015 at 10:24 AM, Jan Nijtmans > wrote: >> >> 2015-04-25 1:29 GMT+02:00 Ron W : >> > Would it be reasonable for Fossil to have a setting, or option in the >> > diff/gdiff command setting, to indicate that relative paths should be >> > supplied? >> >> You suggestion has been heard, and it's fixed here: >> <http://www.fossil-scm.org/index.html/info/3ffb6a3e6299e92f> >> (at least for this specific case, I'm sure there are more ...) > > > Thinking about it, probably the PGP and SSH external commands, as well. Well, my change has been put aside, as being a "Breaking change". I fundamentally disagree with that, but I would like to hear Joe's arguments about that. So, Joe, please explain! My guess is that Joe was mislead by the comment, without looking at the code at all: It's not the path of the external tool (diff/pgp/ssh) that's modified (therefore the PGP/SSH suggestion is not valid, sorry ...), that would indeed be a breaking change. It's just taking care that the _arguments_ provided to the external diff tool are relative paths in stead of absolute paths, as is done almost everywhere else in fossil (e.g. when calling the commit/stash comment editor). @Joe: please, evaluate this "pending-review" properly, and don't throw it away without joining this discussion. There are too many "pending-review" leaves already which were never looked at properly. 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] relative vs full path for external diff command
2015-04-25 1:29 GMT+02:00 Ron W : > A new coworker opted to use Cygwin on her PC rather than have a second PC > with Linux. The external gdiff command she configured is winmerge.exe - a > Windows application. > > In the Cygwin command window, she did a "fossil gdiff". Winmerge complained > about > "/cygdrive/c/Projects/JL_PEPS_KVM/code/source/drv/s12xe_cw450/mcu_s12xe_init.c~0" > not found. > > Would it be reasonable for Fossil to have a setting, or option in the > diff/gdiff command setting, to indicate that relative paths should be > supplied? > > As a workaround, I made a Perl wrapper for winmerge that replaces a leading > "/cygdrive/x" with "x:". while this works, it is an extra layer of > indirection. You suggestion has been heard, and it's fixed here: <http://www.fossil-scm.org/index.html/info/3ffb6a3e6299e92f> (at least for this specific case, I'm sure there are more ...) 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] Version 1.33
2015-06-02 15:33 GMT+02:00 Thomas Bilk : > I managed to recreate the problem in Opensuse 13.2 maybe there is a > problem there. You'll be happy to hear (I hope) that the problem has been located and it's fixed here: <http://fossil-scm.org/index.html/info/8184f39d803f9ad6> 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] Version 1.33 - /reports failing
2015-06-02 9:22 GMT+02:00 Jan Nijtmans : > I'm seeing the same problem in /reports. See below. However, > if I remove the -O2 compiler flag from the Makefile, everything > works fine. So, this could be a gcc optimization bug. It turns out not to be a gcc optimization bug after all: the optimization is very valid, the fossil code just makes an invalid assumption (that azView[] is still available after the if() , it's needed in style_footer()) Fixed here: <http://fossil-scm.org/index.html/info/8184f39d803f9ad6> 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] Version 1.33 - /reports failing
2015-06-02 1:07 GMT+02:00 Richard Hipp : > Start in an open check-out for the repository that you want to serve. > (This is not strictly necessary, but it makes things a little easier.) > Then do "gdb fossil". Then "run test-http". You will not be > prompted, but Fossil is waiting on an HTTP request. Enter "GET > /reports" following pressing Enter twice. Note that in test-http > mode, Fossil is forgiving of the HTTP request syntax and allows you to > omit the HTTP/1.0 at the en dof the first line, for example. I'm seeing the same problem in /reports. See below. However, if I remove the -O2 compiler flag from the Makefile, everything works fine. So, this could be a gcc optimization bug. $ gcc --version gcc (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll see if I can trace this somewhat further, but gdb's "bt" shows nothing :-( Regards, Jan Nijtmans $ gdb ./fossil GNU gdb (GDB) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./fossil...done. (gdb) run test-http Starting program: ./fossil test-http [New Thread 8860.0x6d0] [New Thread 8860.0x1db0] [New Thread 8860.0x1d38] [New Thread 8860.0x2200] GET /reports 0 [main] fossil 8860 cygwin_exception::open_stackdumpfile: Dumping stack trace to fossil.exe.stackdump [Thread 8860.0x1d38 exited with code 35584] [Thread 8860.0x1db0 exited with code 35584] [Inferior 1 (process 8860) exited with code 0105400] ___ 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] SQLITE_ERROR using "fossil mv --hard"
2015-05-26 20:46 GMT+02:00 Taylor Venable : >>>> Error #1: Moving existing files to curdir > RENAME a dir/a > RENAME b dir/b > cannot open "/home/taylor/tmp/fossil/move/repo/dir/a" for reading >>>> Error #2: Moving non-existent files to curdir > SQLITE_ERROR: no such table: fmove Thank you for your report. Should be fixed here: <https://www.fossil-scm.org/index.html/info/89212c5a69576f77> 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
[fossil-users] Version 1.33 win64
2015-05-23 13:47 GMT+02:00 Richard Hipp wrote: > Fossil version 1.33 has been tagged. Binaries are available on the > download page: https://www.fossil-scm.org/download.html > > -- > D. Richard Hipp > d...@sqlite.org For anyone interested, I built fossil 1.33 especially for win64, it's available here: <https://sourceforge.net/projects/cyqlite/files/fossil/> This binary is compiled with latest MinGW-w64 compiler, and with json support, ssl support, tcl support, th1-docs and th1-hooks support and with legacy-mv-rm support. (If you don't know what this all means, you probably don't need it but it won't hurt either) 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] fossil clean --verily too strong???
2015-04-29 14:54 GMT+02:00 Richard Hipp : > I don't mind the keep-glob setting as long as I have a convenient way > to always override it (--verily). I'm happy with trunk. Sure, but your reasoning indicates that this never should have been set as a versioned setting: Those settings are convenient in MY build environment, but they should not have beeen imposed on others with different environments. I didn't realize that at the time. 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] fossil clean --verily too strong???
2015-04-29 14:21 GMT+02:00 Richard Hipp : > It was the (unpleasant) discovery of these patterns in the versioned > keep-glob setting of Fossil that prompted me to strengthen --verily to > overcome them. When I want to remove unmanaged files, I want to > remove them *all*. Understood! In that case I propose to remove the versioned "keep-glob" setting: <http://www.fossil-scm.org/index.html/info/07fb7f64f44b62fc> Would that be acceptable to you? I never understood the need for "keep-glob" in addition to "ignore-glob", as they actually do the same: The versioned setting content for those is even the same. 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
[fossil-users] fossil clean --verily too strong???
Hello all, First to tell, I'm very glad about the strenghtening of "fossil clean --verily". Second, I would like to keep the --keep option and the "keep-glob" setting function as earlier. There are two reasons: - In the fossil self-hosting repository, "keep-glob" looks as follows: $ cat .fossil-settings/keep-glob compat/openssl* compat/tcl* fossil fossil.exe win/fossil.exe this is for a purpose: In compat/openssl* and compat/tcl* there sometimes are (temporary) tcl/openssl builds, which I wouldn't like to be removed completely. If I want to remove them, I simply do "rm compat/openssl*", I don't need fossil for that. The fossil executables are there to make sure that "./fossil clean --verily" wouldn't try to remove itself while running. Those are the only two practical uses of --keep/"keep-glob" I am aware of, at least, that's how I am using it. - How about "fossil clean --verily --keep Makefile"? Despite the -keep option, the Makefile will still be removed. Regarding the other strengthening options, I agree! 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
Re: [fossil-users] Two trunks?
2015-04-27 23:27 GMT+02:00 bch : > Apparently the "automatic fork check" is in trunk. Which commit caused the regression? Two possibilities: a) <https://www.fossil-scm.org/index.html/info/560483f50436c9f7> b) <https://www.fossil-scm.org/index.html/info/f78cba5c9994222f> 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] Testing. Was: Two trunks?
2015-04-26 12:54 GMT+02:00 Richard Hipp : > Yes, but it is not a fork. And so we shouldn't call it "fossil forks" > since that would prevent us from creating a "fossil forks" command > that actually lists real forks. > > Perhaps the command should be "fossil warnings" or "fossil concerns" > and it should report all topological features that are worrisome to > some users. (Are there any other graph topology features besides > multiple leaves on the same branch that people are concerned about?) Or, maybe just combine it with "fossil info" and use the more general term "ambigeous branch" (of which "fork" is a special case) <https://www.fossil-scm.org/index.html/info/4359bd8df2119799> 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] Testing. Was: Two trunks?
2015-04-25 22:54 GMT+02:00 Richard Hipp : > On 4/25/15, Jan Nijtmans wrote: >> 2015-04-25 18:38 GMT+02:00 Andy Bradford: >> So, let's start testing: >> <https://www.fossil-scm.org/index.html/info/560483f50436c9f7> > > The "fossil forks" command applied to SQLite reports these four > check-ins as forks: > > https://www.sqlite.org/src/timeline?c=763d2bc74b&unhide > https://www.sqlite.org/src/timeline?c=7d445e593a&unhide Those are two tips, both originating from trunk, which both has the same branch-name. Although not exactly matching the definition of fork, they should have been closed before unhiding. So, yes, they indicate a potential problem, I would like "fossil forks" to report this. Remedy: both of those leaves should be closed. > https://www.sqlite.org/src/timeline?c=cbea02d938&unhide > https://www.sqlite.org/src/timeline?c=bf6ca21b36&unhide The same here: there are two tips with branch-name "branch-3.7.16" which forked off trunk. Although not matching the definition of fork, it's a potential problem which I would like to be reported by "fossil forks". Remedy: close at least the second one (but the first one probably as well) 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] Two trunks?
2015-04-25 18:38 GMT+02:00 Andy Bradford: > Yes, I would like this to be in ``testing'' sufficiently long to > actually encounter a fork through the normal course of activity. I > analyzed the historical fork count and it seems like there are 6 forks > per year on average in Fossil. We have had only 1 so far this year. So, let's start testing: <https://www.fossil-scm.org/index.html/info/560483f50436c9f7> Keep good comments coming .! 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
Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)
2015-04-23 3:50 GMT+02:00 Andy Bradford : > I've altered the change and now it will only check at the end of the > complete sync. Also, it only warns if it encounters a fork that has not > previously been seen (ignoring any additional checkins on a fork unless > they also are new forks). > > I think this will minimize fork warning fatigue that is an outstanding > concern. Good work, I like it! +1 for merging it to trunk. > I don't think the problem is with ``fossil forks'' however, because > after running ``fossil rebuild'' on z.fossil, ``fossil forks'' correctly > reports that there are no forks. So it seems that for whatever reason, > running ``fossil pull'' the way we are for the test results in not all > nodes being properly designated in the tables. This behavior exists in > trunk as well. > > $ ./fossil forks -R z.fossil >(1) 2015-02-24 06:40:00 [8c3e6404b0] Let -x imply --emptydirs and >--dotfiles (user: jan.nijtmans tags: cleanX-no-clean-glob) >(2) 2013-06-21 09:27:19 [dfb47a2a2e] rebase (user: jan.nijtmans tags: >cleanX-no-clean-glob) >(3) 2013-06-19 07:14:13 [cbf9660369] rebase (user: jan.nijtmans tags: >cleanX-no-clean-glob) >(4) 2013-04-03 07:36:05 [6159a7f281] rebase (user: jan.nijtmans tags: >clean-with-ignore) >(5) 2013-04-02 09:31:26 [bdd9790484] merge trunk (user: jan.nijtmans tags: >clean-with-ignore) Yes, this must be a bug somewhere in the pull handling, which is caused by the "rebase" action I did (as experiment). Have a look at this commit: <http://fossil-scm.org/index.html/timeline?f=2e545d58> You will see that a new "clean-with-ignore" branch was created from trunk, the old content of "clean-with-ignore" being merged in. Even though effectively the branch didn't change, apparently the "pull" concluded that 2e545d58 is a leaf, while "fossil rebuild" correctly decides it isn't. Of course, I could explicitly add a "close" tag here as workaround, but for the sake of bug reproducibility I'll leave it like this ;-) Thanks! Good catch! Pleading guilty! However, as you correctly stated, this is unrelated to the recent fork handling improvements, so still good-to-go from me. 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
Re: [fossil-users] Bug? FOSSIL MV does not work as expected (Win7 machine)
2015-04-21 10:24 GMT+02:00 Michael Richter : > The key wording there is "within the repository tree". > > It doesn't change the file system, only the naming of the files, etc. in the > repository. Whether this is desired or correct behaviour is … an area of > frequent discussion. Work already has been done by Joe Mistachkin to resolve this (Thanks Joe!) Just configure fossil using --with-legacy-mv-rm and then build it, then: ./fossil set mv-rm-files -global 1 I'm currently using fossil compiled this way, and so far it appears to work fine. 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] auto-adjust of CLI timeline to terminal width?
2015-04-20 23:00 GMT+02:00 Warren Young : > It’s a bug in the #includes at the top of src/comformat.c. The following > trivial patch fixes it: Patch applied: <http://fossil-scm.org/index.html/info/d32ca5928223a448> > I have not checked whether this patch causes a portability regression. If > there is in fact a platform where you cannot include sys/ioctl.h if > TIOCGWINSZ isn’t defined by termios.h, a different ifdef will be required. It's very unlikely that a system having would not have . I don't know any. 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
Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)
2015-04-19 2:06 GMT+02:00 Andy Bradford : > The only time that fork detection makes sense (if at all) is *after* a > complete sync in the client. Just repeated my earlier experiment using "sync-forkwarn" branch, and got: $ time ./fossil pull -R z.fossil http://www.fossil-scm.org/index.html Round-trips: 209 Artifacts sent: 0 received: 17734 Pull done, sent: 761275 received: 10502627 ip: 67.18.92.124 * WARNING: a fork has occurred * use "fossil forks" for more details. Hey, the self-hosting fossil repository doesn't contain forks any more, how is this possible? Explanation: the current code in "sync-forkwarn" doesn't do the fork-check at the end of the sync, it does it at the end of each round-trip. Since there were some forks created long ago which were only recently closed, this can result in a false warning: Maybe the artifacts in a round-trip create a fork, but this fork is resolved in some future round-trip which is still part of the same sync operation. It seems it's not wise at this moment to merge "sync-forkwarn" to trunk since false warnings here may be more confusing than that they help :-( 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] Two trunks?
2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger : > On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote: >> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford ... >> I disagree. While it might be the most common case, merging does not >> explicitly state any intent beyond the merge itself, even a full merge. >> After all, a merge doesn't automatically close a named branch. So why would >> a merge automatically make a "fork" not a fork? > > You can still create commits from it, but update will move past it. > That's why it is no longer a fork. Let's try that with a branch which is recently merged to trunk: $ fossil update update-fork-warn updated-to: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10 17:33:18 UTC leaf: closed tags: update-fork-warn comment: Only check for forks on "open" leaves, otherwise we cannot do anything about it from here anyway. Thanks to Andy Bradford for noticing this. (user: jan.nijtmans) changes: 13 files modified. "fossil undo" is available to undo changes to the working checkout. $ fossil update checkout: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10 17:33:18 UTC leaf: closed tags: update-fork-warn comment: Only check for forks on "open" leaves, otherwise we cannot do anything about it from here anyway. Thanks to Andy Bradford for noticing this. (user: jan.nijtmans) changes: None. Already up-to-date Looks like that statement is not true! "fossil update" will only move past it if the branch-name didn't change. I think Andy was right in his statement: the only three ways a fork can be resolved is: 1) "fossil merge" without any arguments, merging the two tips of the fork together. 2) "fossil merge --integrate ": merging to another branch, while implicitely closing . 3) "fossil tag --raw closed " (or close it with the UI) So, a merge which merges the two tips of a fork together indeed closes the fork. But for other merges more needs to be done, that's how it functions (as it should). Sorry ;-) 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] Two trunks?
2015-04-16 13:44 GMT+02:00 Matt Welland : > I'm confused by this. If the fork was merged to trunk it is no longer a fork > and should not be detected. Can you elaborate? In fossil it is possible to merge a branch to trunk, but leave the branch open. It could have been a partial merge, fossil has no way to know that, until the user explicitly closes the branch. Therefore, such a branch needs to be included in the fork-detection. Down to two: $ fossil forks --bybranch *** dg-misc *** (1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user: dg tags: dg-misc) (2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user: dg tags: dg-misc) *** side-by-side-edit *** (3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make the text area small so it will always fit in the column. After page loaded enlarge the text area with Javascript. But leave a little room (40px) as a margin between the two columns. This insurers that side by side always succeeds. (user: renez tags: side-by-side-edit) (4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk changes so that the branches can be more easily compared. (user: drh tags: side-by-side-edit) Analysing those last two, it's not difficult to see what happened: <https://fossil-scm.org/index.html/timeline?n=100&r=dg-misc> <https://fossil-scm.org/index.html/timeline?n=100&r=side-by-side-edit> The oldest commits were nothing more than merging trunk changes into the branch. But later the user forgot about that (without seeing the warning). So it's safe to assume that the older of the two commits will not be continued upon, and can be closed. Done now. The fossil self-hosting repository is fork-free now (FWIW) ! Anyway, we still can test the fork-detection on SQLite ;-) $ fossil forks --bybranch *** branch-3.7.16 *** (1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user: drh tags: release, version-3.7.16.2, branch-3.7.16) (2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process tester to the last released version. (user: mistachkin tags: branch-3.7.16) *** mistake *** (3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX, REINDEX and VACUUM statements by taking better advantage of the fact that index keys are being inserted into b-trees in sorted order. (user: dan tags: mistake) (4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because this commit contains a typo causing a test to fail. Was: Add an extra test to further verify that the FTS notindexed option is working properly. (user: dan tags: mistake) Hope this helps, 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] Two trunks?
2015-04-14 21:11 GMT+02:00 Andy Bradford: > Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200: >> Maybe more valuable would be to adapt the /leaves page, so people >> searching forks have an easy way to do so. > > I proposed this very thing a few days ago, and I think that this is > something that should be done regardless of the discussion on sync > warnings. There's a "fossil forks" command on trunk now: $ ./fossil forks --bybranch *** ben-minorchanges *** (1) 2011-09-07 08:12:27 [27a4518e13c41e] Make it easier to use Events as quick notes: Display the title just above the text on Event pages. If there's no title in the wiki text, use the comment as a title. (user: ben tags: ben-minorchanges) (2) 2011-08-23 08:37:23 [0f0a94730c0ae9] Cache values of versionable settings read from files. (user: ben tags: ben- minorchanges) *** dg-misc *** (3) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user: dg tags: dg-misc) (4) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user: dg tags: dg-misc) *** msw-docco *** (5) 2012-04-19 14:34:59 [626a317e5cea1f] Catch up w/ trunk & document --case-sensitive option in the add and addremove commands. (user: martin.weber tags: msw-docco) (6) 2012-02-10 18:02:40 [587dd57fe194af] climb up the trunk. From up here, clarify wording of the "building and installing" wiki page: you don't need to log in to get the source code for released versions of fossil, the download page will have a shiny source package for you to fetch. (user: martin.weber tags: msw-docco) *** side-by-side-edit *** (7) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make the text area small so it will always fit in the column. After page loaded enlarge the text area with Javascript. But leave a little room (40px) as a margin between the two columns. This insurers that side by side always succeeds. (user: renez tags: side-by-side-edit) (8) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk changes so that the branches can be more easily compared. (user: drh tags: side-by-side-edit) I used this to close some trivial ones (which were already merged to trunk), those are the 4 left at this moment. None of them are harmfull, they all lived happily in the fossil repo for more than a year. 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] Two trunks?
2015-04-14 5:46 GMT+02:00 Andy Bradford : > Thanks. One thing to note is that I extended the function > fossil_find_nearest_fork to be able to work without checking the vmerge > table which is only available for a repository that is open, however, > fossil sync may actually be run with -R and there may or may not be a > vmerge table for that. > > Perhaps a better option would be to check for the vmerge table if it > exists and use it, otherwise don't? I really don't know what would be best here. My only concern is the additional time this check takes when syncing. So, let's do a little stress-test. First create an empty repository in which we are going to pull the complete content of the fossil self-hosting repository: $ fossil new z.fossil ... $ fossil sqlite -R z.fossil SQLite version 3.8.9 2015-04-08 12:16:33 Enter ".help" for usage hints. sqlite> update config set value='CE59BB9F186226D80E49D1FA2DB29F935CCA0333' where name='project-code'; sqlite> .exit So, now we can pull the full content: $ time fossil pull -R z.fossil http://www.fossil-scm.org/index.html Round-trips: 344 Artifacts sent: 0 received: 30646 Pull done, sent: 1124980 received: 19585724 ip: 67.18.92.124 real27m21.480s user1m18.421s sys 0m25.240s Now, repeat the same steps but using fossil compiled from the "sync-forkwarn" branch: Round-trips: 362 Artifacts sent: 0 received: 30646 Pull done, sent: 1186697 received: 19659128 ip: 67.18.92.124 * WARNING: a fork has occurred * real25m49.494s user1m18.780s sys 0m27.752s Conclusion: 1) The fork-detection during sync works, the fork in the "dg-misc" branch is detected correctly. 2) The additional time spent in the fork-detection is negligible. The fork in "dg-misc" is already there for more than a year without causing any harm. I really doubt the value of this WARNING, since there is no clue at all where the fork is. Most people won't have any idea why the warning was there, and what to do about it. I guess it will only cause more confusion than that it helps people getting the repository fork-free. Maybe more valuable would be to adapt the /leaves page, so people searching forks have an easy way to do so. Just my 2c 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] Two trunks?
2015-04-13 6:31 GMT+02:00 Andy Bradford : > It's not yet merged to trunk, but I have borrowed from Jan's work and > merged into the sync-forkwarn branch for what I think will provide a > better experience (e.g. almost no false positives). > > I say almost none, because it's possible that if your sync is cut-off, > you may end up with a node that has a fork which has already been > merged, but for which you didn't receive the correction (what are the > odds?). > > But on the whole, I think this is much more reliable: > > https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6 > Just two remarks: - I'm not sure if I want to be reminded when someone else causes a fork on a branch I'm not working on. But if there is such a desire with other people, I'm not principally against it. - The function primary_parent_pid_from_rid() is not used anywhere. I went ahead, so the fork detection for fossil update/status/info (I din't hear anyone against that) will receive some more wide-spread testing. I'll do more testing on the "sync-forkwarn". Any more feedback welcome! 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] fossil diff -tk on OS X
2015-04-03 23:49 GMT+02:00 jungle Boogie : > Hi Jan, > And when I run: > ./configure --with-tcl=/usr/local/bin/tclsh8.6 I always use: ./configure --with-tcl --with-tcl-stubs --with-tcl-private-stubs . Then fossil won't need the tcl installation at compile-time, but will do the right things at run-time. Yes, this should be documented better.. 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] fossil diff -tk on OS X
2015-04-03 18:32 GMT+02:00 Remco Schoen : > Is there a way to check versions of Tcl and Tk? If fossil is compiled with Tcl support: $ fossil version -v This is fossil version 1.32 [5811ecd7cc] 2015-03-20 14:50:16 UTC Compiled on Mar 20 2015 22:21:56 using gcc-4.9.2 (64-bit) SQLite 3.8.8.3 2015-02-25 13:29:11 9d6c1880fb Schema version 2015-01-24 zlib 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.2a 19 Mar 2015) TCL (Tcl 8.6.0, loaded TH_OK: 8.6.4) USE_TCL_STUBS TCL_PRIVATE_STUBS JSON (API 20120713) UNICODE_COMMAND_LINE If fossil is compiled without Tcl support, "fossil diff --tk" still works, it just invokes "tclsh" to do the real work: $ tclsh % info patchlevel 8.6.4 % (Current Tcl/Tk trunk is not renumbered to 8.6.5 yet, that normally is done just before a new release) 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] fossil diff -tk on OS X
2015-04-03 9:06 GMT+02:00 Remco Schoen : > Hi, > > I use mainly MacBooks for my work and OS X doesn't put the diff-window in the > foreground and even last in the used applications list. This would always > mean a lot of ALT-TAB-ing or SHIFT-ALT-TAB to reach it. That is quite > cumbersome :) Sounds like this bug in Tk, which is recently solved on trunk: <http://core.tcl.tk/tk/info/0a4571b76a3e66c8> In Tk 8.5.18/8.6.5 this should be fixed. 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] TH1: Th_ToInt() issue
2015-04-01 10:18 GMT+02:00 Sergei Gavrikov :
> Hi
>
> This check
> http://fossil-scm.org/index.html/artifact/f3e2d60ea44acd11?ln=2651-2653
> allows to interpret "-" or "+" as valid integer, 0. By mistake, I
> entered "-" in stead "0" in my script and catch this.
No, this is not expected. The n>0 check should have been n>1 here.
In Tcl 8.6:
$ tclsh8.6
% for {set i -} {$i<3} {set i [expr {$i+1}]} {puts $i\n};
-
can't use non-numeric string as operand of "+"
%
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
Re: [fossil-users] SVN-fs-dump-format-version: 3 will produce unusable blobs
2015-03-20 16:55 GMT+01:00 Kain Abel :
> I hope someone can reproduce this behavior:
Yes, I can reproduce that.
See:
<https://svn.apache.org/repos/asf/subversion/branches/1.5.x/notes/dump-load-format.txt>
The conclusion is that "fossil import --svn" only understands version 1 and 2
from the svn dump-load-format, version 3 is not yet implemented.
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] Convenient command for standardizing and simplifying marking a commit as a mistake.
2015-03-20 13:41 GMT+01:00 Stephan Beal : >> I wonder why there isn’t a command for simplifying the process of marking >> a commit as a mistake. So with a single command, fossil will: >> ·The mistaken commits will be hidden from the timeline. > > i have always disliked the hiding feature. I like the hiding feature ... ;-) ... but it should be used sparingly just as shunning. It shouldn't be made too easy, otherwise people will be more sloppy because any mistake can be corrected easily anyway. >> ·If any of the mistaken commits have been merged into another >> branch, the mistaken commits will be backed out from the valid branches. > > That implies automatically committing after backing out, which makes some > people nervous, as it amounts to checking in untested changes. There are > failure cases here, e.g. when multiple branches merge into the line which > this op would want to back something out of. Agreed. I don't think any simplification would be a good idea. Sorry! 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] multiple independent check-outs against the same repository
2015-03-20 4:56 GMT+01:00 Richard Hipp : > I rue the day that I allowed that patch to land on trunk. > But it is all fixed now - you won't have the problem with 1.32. Note that the "initial empty commit" is an unique feature of fossil, GIT and SVN don't have that. Abilio started with a completely empty repository and started committing from two different (empty) checkouts. That means the two file sets committed don't have any relation. If you use fossil 1.32 for doing the same, there will be an additional initial empty commit, which suggests a relation which isn't really there. The only problem I see in your workflow is that you were not warned that actually you were creating a fork, in 1.32 you will get that warning (after doing the same steps): $ fossil commit -m "commit b" would fork. "update" first or use --allow-fork. Thank you for your report. 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] missing initial empty check-in & repository from import
2015-03-13 15:56 GMT+01:00 Marcel Graf : > Well, to kind of answer my own question: I tried it, and yes, it happens > too. Only using fossil version 1.27! Interesting. Thanks! Another way to trigger the 'problem' is using "fossil reconstruct". This function reconstructs the repository from artifacts on disk, it is very unlikely that the initial empty checkin is encountered as first artifact and given rid=1. So, if the requirement is that rid=1 must contain the manifest of the initial empty check-in, the "fossil reconstruct" command builds an incompatible repository by design :-) 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] How to fix parallel timeline
2015-03-13 8:49 GMT+01:00 Stephan Beal : > Richard mentioned earlier that he will remove the "no initial commit" bits, > which will (theoretically, at least) eliminate this problem for future > versions. i would hate to see it go +1 > (not enough to raise a fuss about it), > but it should never have ever been made the default, to avoid compatibility > problems like this one. There was a long thread related to this on May 31st, > 2014: > > https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html The source of this problem was the (past) assumption in the code that the initial commit has rowid=1 and it doesn't contain any files. This bug was fixed here (16 months ago, available since fossil 1.28): <http://fossil-scm.org/index.html/info/6791ad1185f374dc> If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Therefore I respecfully disagree (based on what I read in this thread) with Richard's conclusion that work has been lost due to fossil, but David Mason should have the final word on that (the DELETE's in David's original story meant that those _unchanged_ files were removed from the working copy, but they still were in the repository even though they were invisible to the students). Thanks to Tontyna for his excellent analysis, which made it (at least to me) fully clear what really happend here. 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] How to fix parallel timeline
2015-03-12 15:22 GMT+01:00 Richard Hipp : > The "fossil rebuild" is not necessary. All they have to do is use > Fossil 1.27 to clone a repo that was created with Fossil 1.30. Much better, preventing the problem all together: create the repository with Fossil 1.27 to begin with. Fossil <1.30 had bugs which ill-treat repositories without any commits. Those were fixed in Fossil 1.30. A workaround: If you really want to create the initial repository with Fossil 1.30, use "fossil new --date-override now". 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] Justification for two-step mv and rm
2015-03-09 23:06 GMT+01:00 Tontyna : > Hurray and thank you! > > Will `addremove` become `addforget`? (Sorry, couldn't resist nitpicking.) It should be 'addforgetrename', with the added functionality that renames are detected too .... ;-) 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] Justification for two-step mv and rm
2015-03-06 16:58 GMT+01:00 Jan Danielsson : > On 06/03/15 15:10, Jan Nijtmans wrote: >> Any objections against adding "fossil forget" as alias >> to "fossil rm" If not, I'll be glad to add it, awaiting >> further discussion. > >No objection. I'm even going to go so far as to say I'll be cheering > you on. Done now: <http://www.fossil-scm.org/index.html/info/8cf976d24689ae9e> This means that whatever happens with "fossil rm|mv|delete", the "fossil rename" and "fossil forget" will continue to function as they do now. 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] Justification for two-step mv and rm
2015-03-06 1:32 GMT+01:00 jungle Boogie : > On 5 March 2015 at 12:49, Roy Marples wrote: >> Add flag -f to mv and rm to do this? >> Allows the desired feature and is sort of similar to CVS >> >> fossil mv -f file1 file2 >> fossil rm -f file1 file2 > > Yes, this seems simple and easy enough to type. There may be some > objections as it may be be full featured, though. The biggest problem with "fossil rm" and "fossil mv" is that it suggests to remove/move a file on the file system, but it doesn't. In stead it makes fossil forget/rename the file in the repository. "fossil rename" already exists as alias to "fossil mv", so I suggest to add "fossil forget" as alias to "fossil rm". Then later the behavior of fossil rm/mv" can be modified, while forget/rename will continue to behave as rm/mv do now. Any objections against adding "fossil forget" as alias to "fossil rm" If not, I'll be glad to add it, awaiting further discussion. 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] Fossil's reported app name under Windows firewall
2015-03-01 21:31 GMT+01:00 : > I finally located it under this unsuspecting name: > > "Simple, high-reliability, distributed software configuration management > system." > > Yes, this whole thing. It seems more like an advertisement for an unnamed > product than an application name. But if you must keep it this long, can > you at least make it just a bit longer by adding the word Fossil in the > beginning to make it easier to locate? Done as requested: <https://www.fossil-scm.org/index.html/info/4f4ef542a421e054> I never would have thought "FileDescription" in the resource to be used this way. 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] JavaScript error in
2015-02-25 19:01 GMT+01:00 Richard Hipp :
> On 2/25/15, Kai Lauterbach wrote:
>> During this work I got serious error messages in my browser console:
>> Uncaught SyntaxError: Unexpected token }
>> function gebi(x){
> ^- Opening curly brace
>> if(/^#/.test(x)) x = x.substr(1);
In the previous line, a regular expression is used, which is
only available in javascript 5.1 and higher. My guess is
that your browser uses a javascript version older than that.
>> var e = document.getElementById(x);
>> if(!e) throw new Error("Expecting element with ID "+x);
>> else return e;}
> ^- Close curly brace
>>
>
> What am I overlooking?
Possible workaround (which is hardly more complicated) here:
<http://fossil-scm.org/index.html/info/e7ec49815b988811>
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] Tags and unhide
2015-02-24 20:37 GMT+01:00 bch : > Tags are symbolic names that may or may not be propagate -- a branch > name is an example of a propagating tag, and a non-propagating tag may > be (for example) a tag that marks a specific commit as a "release" > (see: http://fossil-scm.org/index.html/timeline?r=version-1.30) -- if > a branch is marked as "closed", it is (by default) hidden That's not quite accurate. A closed branch doesn't show on the "leaves" page and cannot be added further commits. A "hidden" branch is just a branch which has the "hidden" tag, this tag has to be set explicitely. 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] compiling on branches svn-import* are broken
2015-02-22 16:17 GMT+01:00 Martin Gagnon : > I don't know for msvc 2012, but it compile fine on MinGW. > (with small warning that have to be fixed) > > Unfortunately I don't have access to a msvc 2012 compiler right now. Should be fixed 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] No "extras" files when built with mingw32-4.0-gcc-4.8.1
2015-02-20 14:28 GMT+01:00 Tontyna : > When compiled with mingw32-4.0-gcc-4.8.1 (32-bit) the 'extras' command > doesnt list any new files (Windows 7 64Bit, MSYS shell). > > Reason is: config.h (and sqlite3.h and tcl.h) defines _USE_32BIT_TIME_T > which forces 'time_t' to be 32bit resulting in readdir() returning a dirent > struct with dirent->d_name not pointing to the filename at all (displaced by > 16 Bytes). > > Maybe the 32bit time_t is required for other parts of Fossil but > vfile_scan() cant find anything. The 32-bit time_t is required to make fossil run on Windows XP with this compiler. > My current workaround is compiling against a modified dirent.h (with > __time64_t instead of time_t) and until now it seems to have no ugly side > effects. See also: <https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c> > But that cant be the solution... > The solution is here: <https://sourceforge.net/p/mingw/bugs/2125/> Unfurtunately, MinGW-4.0 was abandoned due to the many problems the time_t changes introduced. A fix for #2125 was committed to GIT, but they probably will never release it. My advise would be to abandon MinGW 4.0 (as their developers did) and go back to 3.x, or switch to MinGW-w64. 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] BUG: /doc pages on "ckout" not rendered correctly any more.
2015-01-29 11:05 GMT+01:00 Jan Nijtmans : > When starting "fossil ui" locally and then opening the following URL: > > <http://localhost:8080/doc/ckout/www/changes.wiki> > > This page is not rendered correctly any more. With fossil > 1.30 this still was OK. Bisecting shows the following commit > somehow introduced the bug: ><http://www.fossil-scm.org/fossil/info/cfcd9b87dcf54a16> > > Hope this helps. Never mind! The bug was already fixed this morning: <http://www.fossil-scm.org/index.html/info/bdfbbddc8f> My fossil binary still was yesterday's ...;-) 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
[fossil-users] BUG: /doc pages on "ckout" not rendered correctly any more.
When starting "fossil ui" locally and then opening the following URL: <http://localhost:8080/doc/ckout/www/changes.wiki> This page is not rendered correctly any more. With fossil 1.30 this still was OK. Bisecting shows the following commit somehow introduced the bug: <http://www.fossil-scm.org/fossil/info/cfcd9b87dcf54a16> Hope this helps. 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] Creating a commit without a parent
2015-01-22 17:50 GMT+01:00 Ron W : > So, a "bug" was promoted to a feature? Hm, yes, that's one way to look at it. Actually, having more than one "initial" commit is not a bug. The only problem was that the fossil code assumed in some places that there was only one. The bug was that fossil mis-behaved when there were no "initial" commits, and therefore always created one just to be sure. Since fossil 0.30, the initial commit is not special any more. It's a normal commit which simply has no ancestors. And all restrictions on how many of them there should be are gone. It's up to you how to use that. 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
