Re: [fossil-users] fossil cut first charracter of the filename

Hello, Perhaps having fossil manage files outside its own root is not practical to implement/want, I don't know. And can be very confusing and dangerous. I suppose, in that case instead of this reaction: if I change the name of the directory, I don't get error, but the name of file is transfo

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 al

Re: [fossil-users] TH1: set v 0; unset v; info exists v;

On Thu, 9 Jan 2014, Joe Mistachkin wrote: > > Sergei Gavrikov wrote: > > > > Thank you for the fixes! I'm sorry, but, I found yet another issue with > > Th_ExistsVar(). If a variable is not exists, Th_ExistsVar() does clear > > TH stack trace: > > > > Thanks again, fixed here: > > https://ww

Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'

On Thu, 09 Jan 2014 23:24:33 +0100, Richard Hipp wrote: On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff wrote: thanks for this. question: the output of `fossil search' is not chronologically sorted. it should be in my view (top down, that is, from new to old just as the timeline). is this in

Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'

On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff wrote: > > thanks for this. question: the output of `fossil search' is not > chronologically sorted. it should be in my view (top down, that is, from > new to old just as the timeline). is this intended behaviour? > > another observation: I see stran

Re: [fossil-users] Version 1.28 release?

On Thu, 9 Jan 2014 15:35:06 -0500 Richard Hipp 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

Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'

On Thu, 09 Jan 2014 22:01:07 +0100, Richard Hipp wrote: On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff wrote: version 1.28 [6f1b5d6047] gives me memory faults when doing something like `fossil search whatever' #search pattern does not matter ... when executing it on fossil's own timeline

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 >>

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

Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'

On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff wrote: > version 1.28 [6f1b5d6047] gives me memory faults when doing something like > > `fossil search whatever' #search pattern does not matter ... > > when executing it on fossil's own timeline (i.e. in a checkout of the > `fossil' source code). >

[fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'

version 1.28 [6f1b5d6047] gives me memory faults when doing something like `fossil search whatever' #search pattern does not matter ... when executing it on fossil's own timeline (i.e. in a checkout of the `fossil' source code). observed under MacOS 10.8.5. it seems to be related to the len

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? >>

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 3:28 PM, Warren Young 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

Re: [fossil-users] TH1: set v 0; unset v; info exists v;

Sergei Gavrikov wrote: > > Thank you for the fixes! I'm sorry, but, I found yet another issue with > Th_ExistsVar(). If a variable is not exists, Th_ExistsVar() does clear > TH stack trace: > Thanks again, fixed here: https://www.fossil-scm.org/index.html/info/9765b03759 -- Joe Mista

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 a

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 3:15 PM, Warren Young 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. Rich

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

Re: [fossil-users] Small issue with ticket hook script

On Thu, Jan 9, 2014 at 5:58 PM, Mark Janssen wrote: > > > > On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans wrote: > >> 2014/1/9 Jan Nijtmans : >> > I have a different fix >> > in mind, I'll come back on that later. >> >> >> >> Does thi

Re: [fossil-users] Small issue with ticket hook script

On Thu, Jan 9, 2014 at 8:05 AM, Mark Janssen wrote: > ... > The reflected information in the query is the info from before the ticket > update. > I suspect the ticket hook is fired before the actual ticket change > transaction is commited. Would it be possible to reverse this so that the > hook s

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

[fossil-users] relative tags

Fossil has the special tag previous and next to refer to the 2 commits on either sire of the current check out. It would be useful to be able to refer to more distant commits. I am thinking numbers prefixed with either '-' or '+', so '-r -1' would be equivalent to '-r previous', '-r -2' would be th

Re: [fossil-users] TH1: set v 0; unset v; info exists v;

On Sun, 5 Jan 2014, Joe Mistachkin wrote: > Sergei Gavrikov wrote: > > > > It seems this was introduced with Th_ExistsVar() > > > http://fossil-scm.org/index.html/artifact/a561c58c237b3eb43eaf55e6f9cc6a9b8a > 26e5d1?ln=1154-1159 > > (check-in http://fossil-scm.org/index.html/info/4f8c8975bc). As I

Re: [fossil-users] Small issue with ticket hook script

On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans wrote: > 2014/1/9 Jan Nijtmans : > > I have a different fix > > in mind, I'll come back on that later. > > > > Does this work for you? > > Regards, > Jan Nijtmans > __

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 Fossi

Re: [fossil-users] Small issue with ticket hook script

2014/1/9 Jan Nijtmans : > I have a different fix > in mind, I'll come back on that later. Does this work for you? Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@list

Re: [fossil-users] Version 1.28 release?

2014/1/9 Richard Hipp : > 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

Re: [fossil-users] Version 1.28 release?

On Thu, 09 Jan 2014 16:55:17 +0100, Richard Hipp 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".

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans wrote: > 2014/1/9 Richard Hipp : > > Jan - would you like to start the "branch-1.28" containing the SQLite > 3.8.2 > > release? > > > Jan: tnx Everybody: Please download, compile, and tes

Re: [fossil-users] Version 1.28 release?

2014/1/9 Richard Hipp : > Jan - would you like to start the "branch-1.28" containing the SQLite 3.8.2 > release? Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists

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 "bran

Re: [fossil-users] Version 1.28 release?

On Thu, 09 Jan 2014 16:26:35 +0100, Ramey, Christopher wrote: On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp 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 l

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

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp 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 >> >> st

Re: [fossil-users] Confirm commit

On Thu, Jan 9, 2014 at 3:54 PM, Arseniy Terekhin wrote: > Hello, > > When developing, I often execute last command blindly and sometimes it > happens to be `fossil ci -m "text"`. And sometimes I commit, > forgetting that I'm on a wrong branch. So I purpose to add commit > confirmation that contai

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 > wrote: >> 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 al

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 10:12 AM, 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

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.

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

[fossil-users] Confirm commit

Hello, When developing, I often execute last command blindly and sometimes it happens to be `fossil ci -m "text"`. And sometimes I commit, forgetting that I'm on a wrong branch. So I purpose to add commit confirmation that contains number of changes and a branch name. One might say, just be carefu

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 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 automatica

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans 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 late

Re: [fossil-users] Version 1.28 release?

2014/1/9 Richard Hipp : > 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 t

Re: [fossil-users] Version 1.28 release?

On Thu, Jan 9, 2014 at 8:54 AM, Jan Nijtmans wrote: > 2014/1/9 Richard Hipp : > > 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 stabl

Re: [fossil-users] Small issue with ticket hook script

2014/1/9 Mark Janssen : > I tested it with ticket changes from the web interface. That's indeed what I suspected. I have a different fix in mind, I'll come back on that later. Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.f

Re: [fossil-users] Version 1.28 release?

2014/1/9 Richard Hipp : > 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

Re: [fossil-users] Small issue with ticket hook script

On Thu, Jan 9, 2014 at 2:20 PM, Jan Nijtmans wrote: > 2014/1/9 Mark Janssen : > > The reflected information in the query is the info from before the ticket > > update. > > I suspect the ticket hook is fired before the actual ticket change > > transaction is commited. Would it be possible to rever

[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://

Re: [fossil-users] Small issue with ticket hook script

2014/1/9 Mark Janssen : > The reflected information in the query is the info from before the ticket > update. > I suspect the ticket hook is fired before the actual ticket change > transaction is commited. Would it be possible to reverse this so that the > hook script will be executed after the tic

[fossil-users] Small issue with ticket hook script

When I use the following script as a ticket hook: set project simpletask tclInvoke package require http query {SELECT title, status FROM ticket WHERE tkt_uuid=$uuid} { set title [tclInvoke http::formatQuery $title] http -asynchronous -- http://127.0.0.1/cgi-bin/tkt-hook?uui

Re: [fossil-users] fossil cut first charracter of the filename

On Thu, Jan 09, 2014 at 10:45:35AM +0100, Michai Ramakers wrote: > Hello, > > On 9 January 2014 09:43, shtine wrote: > > Hello, > >> > >> Perhaps the error is a bit misleading... Should it be possible to add > >> files that are above the root of the open fossil repository? > > > > This would b

[fossil-users] Using Markdown for tickets and in TH1

All, Attached a patch which will do several things: 1) Add a [markdown ] TH1 command to allow access to the included markdown parser from TH1 2) Slightly tweaked the markdown parser to not produce a pair for strings with at most one newline 3) Changed the default ticket page templates to pro

Re: [fossil-users] fossil cut first charracter of the filename

Hello, On 9 January 2014 09:43, shtine wrote: > Hello, >> >> Perhaps the error is a bit misleading... Should it be possible to add >> files that are above the root of the open fossil repository? > > This would be a nice feature to have. I want to use fossil to manage changes > on linux based V

Re: [fossil-users] fossil cut first charracter of the filename

Hello, Perhaps the error is a bit misleading... Should it be possible to add files that are above the root of the open fossil repository? This would be a nice feature to have. I want to use fossil to manage changes on linux based VPN Routers. Some of my config files live in /etc , some in /o