Hi all,
I put together a quick external script to do full-text searches on
tickets. It's not anything complicated, just creates a sqlite fts table
and dumps all the ticket info into it, which means that it doesn't
update automatically when tickets are updated. Still, I've found it
useful,
On Wed, Oct 23, 2013 at 9:58 AM, Jeff Rogers dv...@diphi.com wrote:
Hi all,
I put together a quick external script to do full-text searches on tickets.
Nice, and thanks for sharing.
It's not anything complicated, just creates a sqlite fts table and dumps all
the ticket info into it, which
On Wed, Oct 23, 2013 at 7:38 PM, Andreas Kupries
andre...@activestate.comwrote:
The nice thing is that fossil doesn't care if there are other tables in
the
database, so nothing changes from fossil's perspective.
Yes.
Not quite! A rebuild does indeed drop all tables which fossil does
On Wed, Oct 23, 2013 at 10:45 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Oct 23, 2013 at 7:38 PM, Andreas Kupries andre...@activestate.com
wrote:
The nice thing is that fossil doesn't care if there are other tables in
the
database, so nothing changes from fossil's
On Wed, Oct 23, 2013 at 7:52 PM, Andreas Kupries
andre...@activestate.comwrote:
Ok, so it has to be a separate database ...
i was going to wait until libfossil gets a rebuild op to propose this, but
now's as good a time as any: i think we should reserve some prefix for user
extension tables,
Jeff's post reminded me that I did some work recently to get ticket
notifications by mail running for the Tcl/Tk and related repositories.
The code and scripts for that are in my
http://core.tcl.tk/akupries/fossil2git
repository. Which I should really rename into fossil-tools now.
Snarfing
On Wed, Oct 23, 2013 at 10:53 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Oct 23, 2013 at 7:52 PM, Andreas Kupries andre...@activestate.com
wrote:
Ok, so it has to be a separate database ...
i was going to wait until libfossil gets a rebuild op to propose this, but
now's as good
On Wed, Oct 23, 2013 at 8:08 PM, Andreas Kupries
andre...@activestate.comwrote:
I generally agree ...
fx_ ? (Fossil eXtension)
Sounds good to me (i was thinking something similar but longer - i like
yours better).
FWIW, using supplemental tables like this is IMO the correct way to add
On Wed, Oct 23, 2013 at 11:17 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Oct 23, 2013 at 8:08 PM, Andreas Kupries andre...@activestate.com
wrote:
I generally agree ...
fx_ ? (Fossil eXtension)
Sounds good to me (i was thinking something similar but longer - i like
yours
On Wed, Oct 23, 2013 at 8:30 PM, Andreas Kupries
andre...@activestate.comwrote:
On Wed, Oct 23, 2013 at 11:17 AM, Stephan Beal sgb...@googlemail.com
wrote:
Having a place to
store client-defined extensions like this is (or will be, at some point)
important for extensibility. (Being able
I see the following strange (for me, anyway) behaviour:
in a cgi-served repo one of my colleagures attached a jpeg-image (two,
atcually) to a new ticket.
when accessing that repo via https, the timeline shows the ticket as well
as the added images including
links showing the file names of
11 matches
Mail list logo
