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
Hello,
On 9 January 2014 09:43, shtine sht...@runway.lv 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
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 p/p pair for
strings with at most one newline
3) Changed the default ticket page templates to
On Thu, Jan 09, 2014 at 10:45:35AM +0100, Michai Ramakers wrote:
Hello,
On 9 January 2014 09:43, shtine sht...@runway.lv 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
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 --
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
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
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 2:20 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
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
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
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
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
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
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 3:54 PM, Arseniy Terekhin sen...@gmail.com 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
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
2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
I have a different fix
in mind, I'll come back on that later.
http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook
Does this work for you?
Regards,
Jan Nijtmans
___
fossil-users mailing
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
On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
I have a different fix
in mind, I'll come back on that later.
http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook
Does this work for you?
Regards,
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 could
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
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 Thu, Jan 9, 2014 at 8:05 AM, Mark Janssen mpc.jans...@gmail.com 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
On Thu, Jan 9, 2014 at 5:58 PM, Mark Janssen mpc.jans...@gmail.com wrote:
On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
I have a different fix
in mind, I'll come back on that later.
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
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
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.
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
On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
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, 09 Jan 2014 22:01:07 +0100, Richard Hipp d...@sqlite.org wrote:
On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
version 1.28 [6f1b5d6047] gives me memory faults when doing something
like
`fossil search whatever' #search pattern does not matter ...
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
On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
On Thu, 09 Jan 2014 23:24:33 +0100, Richard Hipp d...@sqlite.org wrote:
On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
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:
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
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
52 matches
Mail list logo
