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 <bytevolc...@safe-mail.net>: > On Mon, 27 Nov 2017 09:52:19 -0500 > Richard Hipp <d...@sqlite.org> 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(, g.argv[2], -1);
for(i=3; i<g.argc; i++){
blob_appendf(, " %s", g.argv[i]);
}
(void)search_init(blob_str(),"*","*","...",SRCHFLG_STATIC);
___
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] 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 <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] 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 <jan.nijtm...@gmail.com> > 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-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 <sky5w...@gmail.com>: > 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 <orz...@drzewo.org>: > 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 <sql...@mistachkin.com>: > 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 <graf.m.ml+sbf...@gmail.com>: > On Sun, Oct 18, 2015 at 10:38 PM, Joe Mistachkin <sql...@mistachkin.com> > wrote: >> There seems to be a timeline issue: >> >> https://system.data.sqlite.org/index.html/timeline?n=50=all=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 <w...@etr-usa.com>: > 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] SVN-fs-dump-format-version: 3 will produce unusable blobs
2015-08-26 20:16 GMT+02:00 Baruch Burstein bmburst...@gmail.com: 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 jan.nijtm...@gmail.com: $ ./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 remco_sch...@me.com: 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 6:31 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: 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] fossil undo for fossil clean
2015-06-26 21:03 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: 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] Issue with cloning a repo
2015-06-17 15:56 GMT+02:00 Jacek Cała jacek.c...@gmail.com: 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] 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 d...@sqlite.org: On 6/11/15, Michal Suchanek hramr...@gmail.com 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] 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] Version 1.33 - /reports failing
2015-06-02 9:22 GMT+02:00 Jan Nijtmans jan.nijtm...@gmail.com: 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 d...@sqlite.org: 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] Version 1.33
2015-06-02 15:33 GMT+02:00 Thomas Bilk tho...@bilkfamilie.de: 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] SQLITE_ERROR using fossil mv --hard
2015-05-26 20:46 GMT+02:00 Taylor Venable tay...@metasyntax.net: 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
[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] fossil clean --verily too strong???
2015-04-29 14:21 GMT+02:00 Richard Hipp d...@sqlite.org: 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
Re: [fossil-users] fossil clean --verily too strong???
2015-04-29 14:54 GMT+02:00 Richard Hipp d...@sqlite.org: 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] Two trunks?
2015-04-27 23:27 GMT+02:00 bch brad.har...@gmail.com: 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-25 22:54 GMT+02:00 Richard Hipp d...@sqlite.org: On 4/25/15, Jan Nijtmans jan.nijtm...@gmail.com 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=763d2bc74bunhide https://www.sqlite.org/src/timeline?c=7d445e593aunhide 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=cbea02d938unhide https://www.sqlite.org/src/timeline?c=bf6ca21b36unhide 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] Testing. Was: Two trunks?
2015-04-26 12:54 GMT+02:00 Richard Hipp d...@sqlite.org: 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] 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 amb-fos...@bradfords.org: 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] auto-adjust of CLI timeline to terminal width?
2015-04-20 23:00 GMT+02:00 Warren Young w...@etr-usa.com: 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 termios.h would not have sys/ioctl.h. 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] Bug? FOSSIL MV does not work as expected (Win7 machine)
2015-04-21 10:24 GMT+02:00 Michael Richter ttmrich...@gmail.com: 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] How about renaming a fork to fork-*? (Was: Two trunks?)
2015-04-19 2:06 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: 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 jo...@britannica.bec.de: On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote: On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org ... 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 branchname: merging to another branch, while implicitely closing branchname. 3) fossil tag --raw closed uuid (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-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-16 13:44 GMT+02:00 Matt Welland mattrwell...@gmail.com: 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=100r=dg-misc https://fossil-scm.org/index.html/timeline?n=100r=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 5:46 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: 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 amb-fos...@bradfords.org: 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 jungleboog...@gmail.com: 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 9:06 GMT+02:00 Remco Schoen remco_sch...@me.com: 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] fossil diff -tk on OS X
2015-04-03 18:32 GMT+02:00 Remco Schoen remco_sch...@me.com: 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] TH1: Th_ToInt() issue
2015-04-01 10:18 GMT+02:00 Sergei Gavrikov sergei.gavri...@gmail.com:
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 n0 check should have been n1 here.
In Tcl 8.6:
$ tclsh8.6
% for {set i -} {$i3} {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 isoru...@gmail.com: 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] multiple independent check-outs against the same repository
2015-03-20 4:56 GMT+01:00 Richard Hipp d...@sqlite.org: 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] Convenient command for standardizing and simplifying marking a commit as a mistake.
2015-03-20 13:41 GMT+01:00 Stephan Beal sgb...@googlemail.com: 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] How to fix parallel timeline
2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com: 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] missing initial empty check-in repository from import
2015-03-13 15:56 GMT+01:00 Marcel Graf graf.m.ml+sbf...@gmail.com: 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-12 15:22 GMT+01:00 Richard Hipp d...@sqlite.org: 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 tont...@ultrareal.de: 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 jan.m.daniels...@gmail.com: 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 jungleboog...@gmail.com: On 5 March 2015 at 12:49, Roy Marples r...@marples.name 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 to...@acm.org: 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 div class=content
2015-02-25 19:01 GMT+01:00 Richard Hipp d...@sqlite.org:
On 2/25/15, Kai Lauterbach kla...@web.de 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
/script
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 brad.har...@gmail.com: 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 eme...@gmail.com: 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 tont...@ultrareal.de: 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 jan.nijtm...@gmail.com: 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 10:43 GMT+01:00 Andy Gibbs andyg1...@hotmail.co.uk: I am trying to create a commit without a parent, effectively so that I can create a separate stream inside my repository, in no way linked to trunk and all its branches. Use fossil open --empty . $ fossil open --help Usage: fossil open FILENAME ?VERSION? ?OPTIONS? Open a connection to the local repository in FILENAME. A checkout for the repository is created with its root at the working directory. If VERSION is specified then that version is checked out. Otherwise the latest version is checked out. No files other than manifest and manifest.uuid are modified if the --keep option is present. Options: --empty Initialize checkout as being empty, but still connected with the local repository. If you commit this checkout, it will become a new initial commit in the repository. --keepOnly modify the manifest and manifest.uuid files --nested Allow opening a repository inside an opened checkout --force-missing Force opening a repository with missing content See also: close 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] CTE in ticket report
2015-01-22 18:20 GMT+01:00 Sean Woods: Can the logic be updated so that it checks for WITH, in addition to SELECT, so that we/I can use CTEs? http://fossil-scm.org/index.html/info/ae72a652a7 Thanks for the suggestion! 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 ronw.m...@gmail.com: 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
Re: [fossil-users] Cygwin fossil behaviour
2014-12-17 13:53 GMT+01:00 Kai Lauterbach kla...@web.de: this is my software setup: This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC Win 8.1 Cygwin 64bit 2.852 Don't use a win32 build of fossil in a Cygwin shell, interoperation with the windows console doesn't work right then. So, fossil tries to ask you to save the password, but it cannot reach the cygwin console to do that. This is a known problem, but due to the way cygwin interoperates with win32, not much can be done about it. There is a cygwin(64) build of fossil available (1.29 as well), please use that in your cygwin 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] Check your repos! Was: clone/sqlite error
2014-11-27 8:17 GMT+01:00 Stephan Beal sgb...@googlemail.com: And if you (like me) only have a single fossil binary which _is_ that trunk copy, then you'll (like me) need to go download a binary to get you back up an running. One of these days i'll learn to keep a backup binary :/. The same for me, except .. My single fossil binary, which _is_ trunk too is configured with --disable-internal-sqlite. Thanks to that I turned out not to be affected ;-) A related question: The $HOME/.fossil (or $HOME/_fossil on win32) and ckout-dir/.fslckout (or ckout-dir/_FOSSIL_) files are sqlite database files too. Could those become corrupt 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] Corrupt line endings in cat/finfo on Windows with CR+LF files
2014-11-25 16:33 GMT+01:00 Stefan Bellon: If files checked in have CR+LF line endings, then they are correctly put into a local working copy, but when using fossil cat or fossil finfo -p to retrieve the file (via stdout redirection), then the CR gets duplicated, so line endings are no longer CR+LF, but instead CR+CR+LF ... which is ... a problem. See: http://www.fossil-scm.org/index.html/info/f2fc37c063 Thanks 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] Corrupt line endings in cat/finfo on Windows with CR+LF files
2014-11-26 11:13 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com: See: http://www.fossil-scm.org/index.html/info/f2fc37c063 Thanks for your report! A related problem on win32: C:\Users\mefossil cat test/utf16be.txt �� T h i s f i l e c o n t a i n s u t f - 1 6 b e t e x t . T h e p u r p o s e f o r i n c l u d i n g t h i s f i l e i n t h e F o s s i l r e p o s i t o r y i s t o p r o v i d e t h e a b i l i t y t o t e s t F o s s i l ' s h a n d l i n g o f U T F - 1 6 u s i n g i t s o w n r e p o s i t o r y . B r o w s i n g t o t h i s f i l e i n t h e w e b i n t e r f a c e s h o u l d d i s p l a y t h e f i l e a s t e x t o n t h e s c r e e n . W h e n t h e r e a r e c h a n g e s t o t h i s f i l e t h o s e c h a n g e s s h o u l d s h o w u p i n t h ed i f fo u t p u t a n d b e p r o p e r l y d i s p l a y e d o n t h e s c r e e n . T e s t p r o c e d u r e s : 1 . V e r i f y t h a t t h i s f i l e i s c o r r e c t l y d i s p l a y u s i n g t h e / a r t i f a c t w e b p a g e . 2 . V e r i f y t h a t t h i s f i l e i s c o r r e c t l y d i s p l a y e d b y t h e / d o c w e b pa g e . 3 . V e r i f y t h a t c h a n g e s t o a r e c o r r e c t l y d i s p l a y e d b y t h e / f d i f f w e b p a g e . 4 . V e r i f y t h a t t h ef o s s i l d i f f c o m m a n d c o r r e c t l y d i s p l a y s c h a n g e s i n t h i s f i l e . D o t h e s a m e w i t h t h e - - t k o p t i o n . Converting a blob from UTF-8 to Unicode, before writing it to the console, is not a good idea if we are not sure the blob is really in UTF-8. (in this example it's not so bad, because 0-bytes are apparently converted to spaces, but the result could have been be much worse if every non-valid byte sequence is displayed as ��) Fix here: http://www.fossil-scm.org/index.html/info/156ef9ec06 Note: of course, special handling should only be done when really writing to the windows console, not when the console is redirected to a file. 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] Error in Windows with Makefile.mingw
2014-11-26 16:38 GMT+01:00 Richie Adler richiead...@gmail.com: After many builds working properly, this happens: C:/Prog/MinGW/bin/mingw32-make -C src/../compat/zlib PREFIX= LOC=-DASMV -DASMINF OBJA=inffas86.o match.o -f win32/Makefile.gcc libz.a C:\Prog\MinGW\bin\mingw32-make: invalid option -- A C:\Prog\MinGW\bin\mingw32-make: invalid option -- M Usage: mingw32-make [options] [target] ... My guess is that the quotes in line 115 of Makefile.mingw are causing this. mingw32-make has its known limitations, because it uses the Windows cmd shell to do executions in stead of the msys shell, which has quite different quote handling. Better: use msys make. I'm open to suggestions how to fix this. 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
