Re: [fossil-users] Version 1.28 release?
So we have a branch-1.28 which is suppose to be for release. I'm wondering if anybody is actually using and testing it? Note that the self-hosting Fossil website, as well as most other websites I control, like SQLite and Tcl/Tk, are running off of trunk and are thus getting real-world testing of about 60K page-views/day. Is anybody doing that level of testing on the branch? When do we know that the branch is ready to release? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
Thus said Richard Hipp on Thu, 16 Jan 2014 10:48:06 -0500: So we have a branch-1.28 which is suppose to be for release. I'm wondering if anybody is actually using and testing it? I've been using it since it was branched, although my limited use cannot come close to that of fossil-scm.org. As for testing, I did run make tests and had similar results as others. I mentioned some observations about the tests requiring a clean repository in which to run. As for when it is ready... I suppose we need more feedback from those who are running the branch. Andy -- TAI64 timestamp: 400052d8079c ___ 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.28 release?
On Thu, Jan 16, 2014 at 10:48:06AM -0500, Richard Hipp wrote: So we have a branch-1.28 which is suppose to be for release. I'm wondering if anybody is actually using and testing it? I am using it for some personal projects, but not 60K page views/day. No problems here yet. Cheers, -Ben ___ 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.28 release?
On Thu, Jan 16, 2014 at 6:06 PM, Ben Collver bencoll...@gmail.com wrote: On Thu, Jan 16, 2014 at 10:48:06AM -0500, Richard Hipp wrote: So we have a branch-1.28 which is suppose to be for release. I'm wondering if anybody is actually using and testing it? I am using it for some personal projects, but not 60K page views/day. No problems here yet. Ditto for http://fossil.wanderinghorse.net That said, 99% of the time i'm using the trunk, and only remember a very small handful of times where that caused me any grief (all of it minor and quickly resolvable). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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.28 release?
2014/1/13 Mark Janssen mpc.jans...@gmail.com: I am not sure if this is an issue with my MinGW install, but latest trunk fails to build on MinGW. I think it's useful if the official release can also be built on MinGW. http://fossil-scm.org/index.html/info/354288db9c 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.28 release?
On Tue, Jan 14, 2014 at 9:36 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/13 Mark Janssen mpc.jans...@gmail.com: I am not sure if this is an issue with my MinGW install, but latest trunk fails to build on MinGW. I think it's useful if the official release can also be built on MinGW. http://fossil-scm.org/index.html/info/354288db9c 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 With that commit, build still fails on sqlite.c: src/sqlite3.c:34515: warning: implicit declaration of function 'winShmMutexHeld' This function is only defined with -DSQLITE_DEBUG but used without ifdef in winShmPurge. There are many other issues with building without -DSQLITE_DEBUG. I am not sure if the proper fix is to define this in the Makefile or to build without DEBUG. Defining -DSQLITE_DEBUG gives a warning about %lld: src/sqlite3.c:5: warning: unknown conversion type character 'l' in format src/sqlite3.c:5: warning: too many arguments for format src/sqlite3.c:7: warning: unknown conversion type character 'l' in format src/sqlite3.c:7: warning: too many arguments for format Mark BTW you are referring to old MinGW in your commit message. I have installed mingw using the installer. How do you get a newer version? ___ 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.28 release?
2014/1/14 Joseph R. Justice jayare...@gmail.com: (I also note from the timeline that the prospective 1.28 does appear to have a release version of SQLite embedded.) Actually, branch-1.28 doesn't contain a release version of SQLite either, it contains the most stable version. This is almost the same, but not 100%. I'll try to explain (my personal view, but I'm sure I'm not the only one). The most stable version at 2013-12-06 was SQLite 3.8.2, there is no question about it. Proof: http://www.sqlite.org/checklists/3080200/index What does it actually mean, the most stable SQLite? Most people would say, the SQLite version which the least number of bugs. Well, no-one know how much bugs SQLite has, we only know how much bugs are reported and how many are found during testing. There are 6 known bugs in SQLite 3.8.2 (that I am aware of), all of them are fixed in SQLite trunk. Only one of them can cause an exception while executing certain SQL queries: http://www.sqlite.org/src/info/520070ec7fbaac There are 3 bug-fixes in shell.c. Since shell.c is not actually part of SQLite there is actually no issue here. SQLite trunk's shell.c contains only bug-fixes, so the shell.c from there is the most stableone. For those who are interested: http://www.sqlite.org/src/info/5e239ecda0 http://www.sqlite.org/src/info/96397263f9 http://www.sqlite.org/src/info/ac15455abc The two remaining are minor. One that only affects Cygwin: http://www.sqlite.org/src/info/c43b59dac1 And the last one which doesn't affect fossil at all because fossil doesn't use fork(): https://www.mail-archive.com/sqlite-users@sqlite.org/msg81284.html Branch branch-1.28 currently contains SQLite 3.8.2 with 5 additional bug-fixes: All the ones mentioned above except the last one. Of course, this needs approval from Richard. Any more bug-fixes that should go in the branch? Any bug-fixes that I missed? Thank you very much for your attention! 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.28 release?
2014/1/14 Mark Janssen mpc.jans...@gmail.com: With that commit, build still fails on sqlite.c: src/sqlite3.c:34515: warning: implicit declaration of function 'winShmMutexHeld' Should be fixed now in branch-1.28. In trunk it should be fixed as soon as a new SQLite amalgamation appears there. (Already fixed by Joe in SQLite trunk, I just cherry-picked 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] Version 1.28 release?
Thus said Jan Nijtmans on Tue, 14 Jan 2014 10:33:57 +0100: And the last one which doesn't affect fossil at all because fossil doesn't use fork(): https://www.mail-archive.com/sqlite-users@sqlite.org/msg81284.html Technically it does use fork() for SSH sync operations but I don't believe it fits the description in the above mentioned mailing list post because the forked process is an SSH process, not another process with sqlite code running in it (well, ok, it forks SSH which then runs fossil, but clearly the sqlite code running in that process is unrelated). Andy -- TAI64 timestamp: 400052d55469 ___ 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.28 release?
On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users I am not sure if this is an issue with my MinGW install, but latest trunk fails to build on MinGW. I think it's useful if the official release can also be built on MinGW. Error is (using make -f win/Makefile.mingw): src/winfile.c: In function 'win32_access': src/winfile.c:117: error: 'LABEL_SECURITY_INFORMATION' undeclared (first use in this function) src/winfile.c:117: error: (Each undeclared identifier is reported only once src/winfile.c:117: error: for each function it appears in.) make: *** [wbld/winfile.o] Error 1 ___ 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.28 release?
On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? i'm a bit late to the party (been off with a back injury since New Year's Eve), and don't really want to wade through the near-30 responses because sitting up on the PC is still very uncomfortable, so i'll just ask: is there still a need to run the current trunk through valgrind (or similar testing) for the release? i have x64 Mint Linux here i could run it through, but won't do so if the release is already on its way out the door. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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.28 release?
On Sat, Jan 11, 2014 at 6:21 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? i'm a bit late to the party (been off with a back injury since New Year's Eve), and don't really want to wade through the near-30 responses because sitting up on the PC is still very uncomfortable, so i'll just ask: is there still a need to run the current trunk through valgrind (or similar testing) for the release? i have x64 Mint Linux here i could run it through, but won't do so if the release is already on its way out the door. I just now ran the valgrind test script, and there are issues. There is a performance issue in timeline which seems to be related to Unhide. And there is a valgrind error (jump based on uninitialized memory) in the /tar page. Those of the problems I've seen so far. Continuing to investigate -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Sat, Jan 11, 2014 at 9:31 AM, Richard Hipp d...@sqlite.org wrote: I just now ran the valgrind test script, and there are issues. There is a performance issue in timeline which seems to be related to Unhide. The performance problem only comes up with WITHOUT ROWID tables are used (which happens only if you run fossil test-without-rowid on the repository to modify the schema.) It appears to be some problem in the SQLite query planner related to WITHOUT ROWID. Since nobody (besides me) uses WITHOUT ROWID repositories, I don't think this should hinder the release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. 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] Version 1.28 release?
I have a request. Can you guys do the official builds SSL-enabled? On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. 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 ___ 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.28 release?
On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. Thanks! The valgrind error in /tar has now been fixed on trunk. (It was utterly harmless and so it is not necessary to merge the fix into the 1.28 branch.) I'm currently chasing another valgrind error in the diff-er. 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 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote:
On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2014/1/9 Richard Hipp d...@sqlite.org:
Jan - would you like to start the branch-1.28 containing the SQLite
3.8.2
release?
http://fossil-scm.org/index.html/timeline?r=branch-1.28
Jan: tnx
Everybody: Please download, compile, and test the branch above. If there
are no issues reported, it will become the official 1.28 release.
* Final result: 27 errors out of 18957 tests
* Failures: merge-utf-24-23 merge-utf-24-32 merge5-10 merge5-50 merge5-72
merge5-90 merge5-91 merge5-100 merge5-101 merge5-102 merge5-110 merge5-120
merge5-121 merge5-122 merge5-123 merge5-130 merge5-131 merge5-132 merge5-133
merge5-134 merge5-135 merge5-136 merge5-140 merge5-141 merge5-142 th1-setting-5
th1-setting-6
on Linux 3.12.6-1-ARCH x86_64
with gcc version 4.8.2 20131219
from fossil 1f10199a09724a50 (1.28 branch tip)
Side note: failing tests do not print info on stderr (it all goes to stdout
from a 'make test' invocation POV)
Being able to run make test /dev/null 2 errs rm -f errs || ${PAGER:-more}
errs would be nice ;)
-M
___
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.28 release?
more info: test-out @ http://phaeton.sdf-eu.org/fossil-1f10199a09724a50-test-out -M ___ 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.28 release?
On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote: Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. for my info, when you say 'please test', do you mean 'run the test-suite from the build and report errors' or 'try to use it in practice' (or both)? I always do the latter; this is the first time I even run the test-suite. Michai ___ 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.28 release?
On 10 January 2014 13:25, Michai Ramakers m.ramak...@gmail.com wrote: On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote: Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. for my info, when you say 'please test', do you mean 'run the test-suite from the build and report errors' or 'try to use it in practice' (or both)? I always do the latter; this is the first time I even run the test-suite. fwiw: * End of utf: 2 errors so far ** * Final result: 2 errors out of 18915 tests * Failures: merge-utf-24-23 merge-utf-24-32 michai@lime:/tmp/f/f$ uname -a NetBSD lime.LAN 6.0.1 NetBSD 6.0.1 (GENERIC) amd64 michai@lime:/tmp/f/f$ ./fossil version This is fossil version 1.28 [6e7e8fbe01] 2014-01-09 21:00:38 UTC (These are the same errors Jan Nijtmans reported in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14301.html) Michai ___ 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.28 release?
On Jan 10, 2014, at 13:30 , Michai Ramakers wrote: * End of utf: 2 errors so far ** * Final result: 2 errors out of 18915 tests * Failures: merge-utf-24-23 merge-utf-24-32 The same tests are failing on my machine: $ uname -a Darwin pc6.home 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 $ ./fossil version This is fossil version 1.28 [1f10199a09] 2014-01-09 21:12:11 UTC Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
Thank you. But those antique test cases don't really matter that much. (The test failures you are seeing are likely due to problems in the tests themselves, not problems in Fossil, though we will verify this prior to release.) I'm really interested in knowing whether or not the latest Fossil is working well for you in your daily activities and if you know of any bugs or problems with the latest Fossil that need to be addressed before we release. If you want some specific command to run in order to validate Fossil, please try these: fossil all rebuild fossil all test-integrity Let me know if either of these commands gives problems for any of your repositories. Thanks. On Fri, Jan 10, 2014 at 9:23 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 10, 2014, at 13:30 , Michai Ramakers wrote: * End of utf: 2 errors so far ** * Final result: 2 errors out of 18915 tests * Failures: merge-utf-24-23 merge-utf-24-32 The same tests are failing on my machine: $ uname -a Darwin pc6.home 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 $ ./fossil version This is fossil version 1.28 [1f10199a09] 2014-01-09 21:12:11 UTC Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Jan 10, 2014, at 15:29 , Richard Hipp wrote: Thank you. But those antique test cases don't really matter that much. (The test failures you are seeing are likely due to problems in the tests themselves, not problems in Fossil, though we will verify this prior to release.) Well, an error in a test is still an error to fix. If you want some specific command to run in order to validate Fossil, please try these: fossil all rebuild fossil all test-integrity Let me know if either of these commands gives problems for any of your repositories. Thanks. Both worked perfectly. If I happen onto any real-world error, I will not neglect to cry out loud ;) Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
../configure --quietmake -s test|sed -ne '/Final result:/,$p' Cannot run this test within an open checkout Cannot run this test within an open checkout Cannot run this test within an open checkout * Final result: 2 errors out of 18915 tests * Failures: merge-utf-24-23 merge-utf-24-32 cp ../manifest* .fossil close mv manifest* ..make -s test|sed -ne '/Final result:/,$p' * Final result: 27 errors out of 18957 tests * Failures: merge-utf-24-23 merge-utf-24-32 merge5-10 merge5-50 merge5-72 merge5-90 merge5-91 merge5-100 merge5-101 merge5-102 merge5-110 merge5-120 merge5-121 merge5-122 merge5-123 merge5-130 merge5-131 merge5-132 merge5-133 merge5-134 merge5-135 merge5-136 merge5-140 merge5-141 merge5-142 th1-setting-5 th1-setting-6 uname -a Linux ** 3.2.0-56-generic #86-Ubuntu SMP Wed Oct 23 17:31:43 UTC 2013 i686 i686 i386 GNU/Linux Sergei ___ 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.28 release?
On Thu, Jan 09, 2014 at 05:25:04PM +0100, Jan Nijtmans wrote: [snip] I compiled/ran it on Cygwin64, and make test ended with: * Final result: 2 errors out of 18914 tests * Failures: merge-utf-24-23 merge-utf-24-32 [snip] Same thing here on OpenBSD 5.3 amd64... I've also made some real world test including the rebuild and test-integrity on few repos.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
Thus said Sergei Gavrikov on Fri, 10 Jan 2014 19:56:54 +0300: * Failures: ... th1-setting-5 th1-setting-6 These two failures appear to be happening because they expect to find a setting (autosync == 1), but find something else. I believe this is because they operate on the current fossil repository which may or may not have the settings that were originally present when the test was drafted. This means that the test is not operating on a cleanly created fossil repository. Given that we cannot know what state any given repository is in, you probably need to create a new repository and run the tests from there. Something like: FDIR=/path/to/fossil FOSSIL=$FDIR/fossil $FOSSIL new /tmp/test.fossil mkdir /tmp/test; cd /tmp/test; $FOSSIL open /tmp/test.fossil tclsh $FDIR/test/tester.tcl $FOSSIL Or make a new clone of fossil when building/testing and use ``make test'' within that directory. Also, main.mk has this advisory: # WARNING. DANGER. Running the test suite modifies the repository the # build is done from, i.e. the checkout belongs to. Do not sync/push # the repository after running the tests. In the future, perhaps the tests need to be modified to create a new test.fossil from which to run the tests. I cannot tell what modifications might have been made to my clone of fossil, but the warning seems pretty dire---I wonder if that means I can no longer sync? Andy -- TAI64 timestamp: 400052d0bba0 ___ 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.28 release?
It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 9, 2014 at 8:54 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/9 Richard Hipp d...@sqlite.org: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? That's fine with me! I think Fossil's trunk is quite stable now. One thing to consider would be which SQLite amalgamation should be included in it. One way to make both developers and package maintainers happy (as being discussed in Fossil-Users mailing list) could be: 1) Create a branch-1.28 from fossil trunk now (or any other suitable moment in the future). 2) Create a SQLite amalgamation from here: http://www.sqlite.org/src/timeline?r=branch-3.8.2 and replace Fossil's sqlite3.c and sqlite3.h in Fossil's branch-1.28 branch. I view Fossil as supporting SQLite, not the other way around. (Remember, that's why Fossil was original written!) As part of its role of supporting SQLite, Fossil serves as a test platform for the latest SQLite alphas. For that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not the most recent release. Then trunk can be continued to be developed with the latest-and-greatest SQLite version, while Fossil 1.28 will be release with the best-tested-and-most-stable SQLite version. Of course, more bug-fixes could be merged to SQLite's branch-3.8.2 branch, but I don't see any which are relevant to 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 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: I view Fossil as supporting SQLite, not the other way around. (Remember, that's why Fossil was original written!) As part of its role of supporting SQLite, Fossil serves as a test platform for the latest SQLite alphas. For that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not the most recent release. I already expected that answer, and it's perfectly fine. As developer I completely agree with that. But package maintainers prefer to release Fossil with the most stable SQLite, they don't want to play the role as SQLite testers. As (Cygwin) package maintainer (for SQLite, not for Fossil) I completely agree with that. There are two ways package maintainers can get what they want: - Replace Fossil's SQLite amagalmation with whatever they want, probably SQLite 3.8.2 (maybe with backported bugfixes) - Compile Fossil with --disable-internal-sqlite. In both situations, the package maintainers are responsible for whatever bug this introduces in Fossil. The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. I hope this is an important argument for keeping the --disable-internal-sqlite option. 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.28 release?
On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 09, 2014 at 09:31:59AM -0500, Richard Hipp wrote: On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. Regards, -Martin ___ 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.28 release?
On Jan 9, 2014, at 16:00 , Martin S. Weber wrote: But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 9, 2014, at 16:00 , Martin S. Weber wrote: But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. SQLite alphas are more robust that stables of most other software projects. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 09, 2014 at 04:12:31PM +0100, Remigiusz Modrzejewski wrote: On Jan 9, 2014, at 16:00 , Martin S. Weber wrote: But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. As for me, I think that fossil has showed that it works well enough at almost any trunk checkin. I understand that the named version sqlite has already been quite tested; a fossil release with it will only mean *more* tests for sqlite. It sounds good to me. ___ 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.28 release?
On Jan 9, 2014, at 16:14 , Richard Hipp wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. SQLite alphas are more robust that stables of most other software projects. Good point. However, this is one that can be hard to explain to distributors. It would be a shame to see new Fossil releases not adopted due to that. Disclaimer: I have no idea if this would be the case. Personally, knowing SQLite testing, I have nothing against using current version in my system. Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Jan 9, 2014, at 16:00 , Martin S. Weber wrote: But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. SQLite alphas are more robust that stables of most other software projects. I'd be more concerned about the appearance of using a SQLite alpha in Fossil. People have to have a great deal of faith in the quality and stability of their VCS - using anything branded alpha even on the insistence that it's better than most other stables could have a damaging effect on Fossil's reputation. ___ 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.28 release?
Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. Fossil is a critical application that deserves its own shelf. Thanks for Fossil and SQLite! On Thu, Jan 9, 2014 at 10:21 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 9, 2014, at 16:14 , Richard Hipp wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. SQLite alphas are more robust that stables of most other software projects. Good point. However, this is one that can be hard to explain to distributors. It would be a shame to see new Fossil releases not adopted due to that. Disclaimer: I have no idea if this would be the case. Personally, knowing SQLite testing, I have nothing against using current version in my system. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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.28 release?
On Thu, 09 Jan 2014 16:26:35 +0100, Ramey, Christopher cra...@extraarms.com wrote: On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Jan 9, 2014, at 16:00 , Martin S. Weber wrote: But I want Fossil to follow the latest SQLite alphas, not the latest SQLite stables. That's the whole point: Fossil supports SQLite as a test platform. SQLite stable has already been thoroughly vetted and tested and there is little point in testing it further. I want Fossil to run with the latest SQLite on trunk to smoke out bugs early. ...but fossil in itself is a pretty awesome piece of software, that's expected by its users to be stable -- at least for releases. I second this view, Fossil is definitely valuable on its own merit. As such, its stable versions should not contain alpha-quality code from other projects. SQLite alphas are more robust that stables of most other software projects. I'd be more concerned about the appearance of using a SQLite alpha in Fossil. People have to have a great deal of faith in the quality and stability of their VCS - using anything branded alpha even on the insistence that it's better than most other stables could have a damaging effect on Fossil's reputation. +1 were I not already using fossil in the first please, reading that the considered DVCS uses alpha state software for it's database (of all things...) would quite probably put me off immediately. we are talking about a revision control system, not a chat client (or what else). and I really do believe fossil deserves to gain more following in the DVCS wars which aim might be harmed by the proposed approach. personally, I can trust your statement (that the alphas are robust (although a contradiction in terms)) and, therefore, do have no problem in using fossil this way. for newcomers the reaction very very probably will be different. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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.28 release?
A consensus seems to be emerging that perception is more important that truth and hence the latest release of SQLite should be in the Fossil release, rather than the latest trunk version of SQLite. I think that is silly, but I will yield to the consensus. Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? I'll continue to keep the latest SQLite trunk on the Fossil trunk, and run the Fossil trunk on important websites like http://www.sqlite.org/, http://www.fossil-scm.org/, and http://core.tcl.tk/. That will be sufficient testing. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? http://fossil-scm.org/index.html/timeline?r=branch-1.28 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.28 release?
On Thu, 09 Jan 2014 16:55:17 +0100, Richard Hipp d...@sqlite.org wrote: A consensus seems to be emerging that perception is more important that truth and hence the latest release of SQLite should be in the Fossil more important than truth? I think nobody said so and I would not agree to that consensus. the question rather seems whether you care for adoption of `fossil' -- in which case, indeed, perception of the potential new users is a non-negligible factor. personally, I would like to see an increase of the user base and broader acceptance of fossil, especially since `git' (with its tons of gotchas making it ill fit for human-sized projects in my view) increasingly seems to be the only (recognized) game in town. release, rather than the latest trunk version of SQLite. I think that is silly, but I will yield to the consensus. Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? I'll continue to keep the latest SQLite trunk on the Fossil trunk, and run the Fossil trunk on important websites like http://www.sqlite.org/, http://www.fossil-scm.org/, and http://core.tcl.tk/. That will be sufficient testing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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.28 release?
On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/9 Richard Hipp d...@sqlite.org: Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? http://fossil-scm.org/index.html/timeline?r=branch-1.28 Jan: tnx Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: Jan: tnx Your're welcome! Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. I compiled/ran it on Cygwin64, and make test ended with: * Final result: 2 errors out of 18914 tests * Failures: merge-utf-24-23 merge-utf-24-32 This is no big deal: Fossil 1.26 and 1.27 had the same failures, I am convinced that those 2 are test-case errors. 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.28 release?
On Jan 9, 2014, at 16:35 , sky5w...@gmail.com wrote: Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. SQLite QA is so impressive that some may be pretty comfortable with having any version, provided it has passed a full test suite, included in their systems. The problem here is the message sent by the word alpha. What it usually means is I just wrote it, hope it will not explode in your face, but no warranties. Therefore if we want to say Fossil is rock-solid, we can't say it uses alpha libs, just to avoid the confusion, no matter the actual quality. Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
A while back when considering Fossil, I read that 'any' database could have been chosen in its design. This thread seems to contradict Fossil's published design theme? http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki Thoughts On The Design Of The Fossil DVCS: We claim that Fossil is not based on SQLite at all and that Fossil is not based on a distributed NoSQL database because Fossil is a distributed NoSQL database. Fossil Is A NoSQL Database We begin with the first question: Fossil is not based on a distributed NoSQL database because Fossil *is* a distributed NoSQL database. Fossil is *not* based on SQLite. The current implementation of Fossil uses SQLite as a local store for the content of the distributed database and as a cache for meta-information about the distributed database that is precomputed for quick and easy presentation. But the use of SQLite in this role is an implementation detail and is not fundamental to the design. Some future version of Fossil might do away with SQLite and substitute a pile-of-files or a key/value database in place of SQLite. (Actually, that is very unlikely to happen since SQLite works amazingly well in its current role, but the point is that omitting SQLite from Fossil is a theoretical possibility.) I treat Fossil as a standalone and critical app and believe it deserves higher standing than a test bed for SQLite. Thanks for Fossil and SQLite! On Thu, Jan 9, 2014 at 11:52 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 9, 2014, at 16:35 , sky5w...@gmail.com wrote: Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. SQLite QA is so impressive that some may be pretty comfortable with having any version, provided it has passed a full test suite, included in their systems. The problem here is the message sent by the word alpha. What it usually means is I just wrote it, hope it will not explode in your face, but no warranties. Therefore if we want to say Fossil is rock-solid, we can't say it uses alpha libs, just to avoid the confusion, no matter the actual quality. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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.28 release?
On 1/9/2014 07:31, Richard Hipp wrote: But I want Fossil to follow the latest SQLite alphas, So run sqlite.org with Fossil + SQLite alpha. Everyone is free to run Fossil in any configuration they like. Please don't ask the rest of the Fossil user community to alpha-test SQLite for you, using their precious source archives as cannon fodder. SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? ___ 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.28 release?
On Thu, Jan 9, 2014 at 3:15 PM, Warren Young war...@etr-usa.com wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On 1/9/2014 13:17, Richard Hipp wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? I'll take you at your word. I'm not going to go trawl the SQLite changelog to try and prove you wrong. I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. I have no problem with you asking people to volunteer for such a test. [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. ___ 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.28 release?
On Thu, Jan 9, 2014 at 3:28 PM, Warren Young war...@etr-usa.com wrote: I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. The fact that you feel this way (and that you probably represent the views of many others who haven't bother to comment) shows that Jan is correct, and that we really need to back up to the last version of SQLite that is deemed stable for the release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Jan 9, 2014, at 21:28 , Warren Young wrote: On 1/9/2014 13:17, Richard Hipp wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? I'll take you at your word. I'm not going to go trawl the SQLite changelog to try and prove you wrong. I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. Exactly my point about message sent by the alpha word. [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. The fact that Fossil is sort of write-only should. By design Fossil does not allow changing (thus destroying) any historical records. The only unwanted thing that can conceivably propagate is your CC number in a test file. If you are concerned by new software errors eating your code, simply don't update your central location. Fossil can easily interoperate in the distance of many versions. Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
Am Donnerstag, 9. Januar 2014, 13:15:30 schrieb Warren Young: On 1/9/2014 07:31, Richard Hipp wrote: But I want Fossil to follow the latest SQLite alphas, So run sqlite.org with Fossil + SQLite alpha. Everyone is free to run Fossil in any configuration they like. Please don't ask the rest of the Fossil user community to alpha-test SQLite for you, using their precious source archives as cannon fodder. +1 SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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.28 release?
On Jan 9, 2014, at 21:38 , Remigiusz Modrzejewski wrote: [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. The fact that Fossil is sort of write-only should. What I meant is obviously append-only. By design Fossil does not allow changing (thus destroying) any historical records. The only unwanted thing that can conceivably propagate is your CC number in a test file. If you are concerned by new software errors eating your code, simply don't update your central location. Fossil can easily interoperate in the distance of many versions. Kind regards, Remigiusz Modrzejewski ___ 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.28 release?
On Thu, 9 Jan 2014 15:35:06 -0500 Richard Hipp d...@sqlite.org wrote: The fact that you feel this way (and that you probably represent the views of many others who haven't bother to comment) shows that Jan is correct, and that we really need to back up to the last version of SQLite that is deemed stable for the release. I trust your QA of Fossil, but, at the same time, wishing that Fossil become spread more widely, believe it's better not to be 'shipped' with alpha-labelled SQLite code. Sincerely, Gour ___ 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.28 release?
Am 09.01.2014 17:52, schrieb Remigiusz Modrzejewski: You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. Well, can I come in here? Maybe alpha and beta are just words, but they are used for a reason. The reason is, that the software in these states is not fully tested and not to be considered stable. Therefore the software should not under any circumstances be used in productive environment. So please, if anyone is going to give a stable release, do not use alpha or beta dependencies on it, because that makes your software alpha or beta for a reason. There is nothing that tells me, if I'm using a stable release of fossil, if my repository is getting fucked up by a feature from the alpha/beta sqlite. Maybe sqlite has a very very good QA and the software is extremly stable, but even the own developers do not trust the version as stable - so why should we? regards, Oliver ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
