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
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.
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
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
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
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
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
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.
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
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
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
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?
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
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!
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
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
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?
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
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
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
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
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
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
../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
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
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
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
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
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
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
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
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
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.
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
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.
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.
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
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:
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
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
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
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
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
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
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
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,
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?
--
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
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
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.
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
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
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
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
54 matches
Mail list logo
