Re: [fossil-users] (no subject)
On 28 February 2015 at 21:50, Andy Bradford wrote: > Thus said Michai Ramakers on Sat, 28 Feb 2015 10:44:59 +0100: > >> I'll pick this one up. Did you mean to change the actual option-names >> too? > > My vote is to leave checkin without the dash, and after a bit of sed, > Knuth would agree: > > lynx --dump http://www-cs-faculty.stanford.edu/~uno/email.html | > sed -e 's/[Ee]\([-]*\)mail/check\1in/g' Nothing functional was changed, just code-comment, fatal error descriptions, help-text and some generated web-content. Everything related to options and arguments was left as-is. 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] (no subject)
Thus said Michai Ramakers on Sat, 28 Feb 2015 10:44:59 +0100: > I'll pick this one up. Did you mean to change the actual option-names > too? My vote is to leave checkin without the dash, and after a bit of sed, Knuth would agree: lynx --dump http://www-cs-faculty.stanford.edu/~uno/email.html | sed -e 's/[Ee]\([-]*\)mail/check\1in/g' Andy -- TAI64 timestamp: 400054f22a45 ___ 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] (no subject)
On Sat, Feb 28, 2015 at 3:40 PM, Andy Bradford wrote: > Thus said jungle Boogie on Fri, 27 Feb 2015 12:17:15 -0800: > > > Can this be updated to check-in as we are graduating from checkin? > > Personally, I prefer checkin without the dash, and definitely for a > command argument, adding yet one more character to type seems like a > waste, not to mention all the scripts that might potentially break from > such a change. Maybe have check-in as a synonym, rather than replacement, for checkin ___ 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] (no subject)
Thus said jungle Boogie on Fri, 27 Feb 2015 12:17:15 -0800: > Can this be updated to check-in as we are graduating from checkin? This is the first time I've heard anything about ``graduating from checkin.'' Why? What purpose can making such a change serve? Especially where command arguments are involved, this seems like not a very good thing. Personally, I prefer checkin without the dash, and definitely for a command argument, adding yet one more character to type seems like a waste, not to mention all the scripts that might potentially break from such a change. Just my $0.02 Andy -- TAI64 timestamp: 400054f227cc ___ 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] (no subject)
Hi Michai, On 28 February 2015 at 05:25, Michai Ramakers wrote: > Hello, > > On 28 February 2015 at 14:13, jungle Boogie wrote: >> On 28 February 2015 at 01:44, Michai Ramakers wrote: >>> I'll pick this one up. Did you mean to change the actual option-names too? >> >> No, that was probably a mistake and my misunderstanding of the >> comments vs. options. > > ok > >> What do you recommend regarding option names? It's easier to type >> checkin but easier to read check-in. > > Well... I would think twice before changing option names (possibly > breaking scripts out there). Yes, very good point. I like the changes you did here: https://www.fossil-scm.org/fossil/ci/7c30266a4558d656 > > Michai -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] (no subject)
Hello, On 28 February 2015 at 14:13, jungle Boogie wrote: > On 28 February 2015 at 01:44, Michai Ramakers wrote: >> I'll pick this one up. Did you mean to change the actual option-names too? > > No, that was probably a mistake and my misunderstanding of the > comments vs. options. ok > What do you recommend regarding option names? It's easier to type > checkin but easier to read check-in. Well... I would think twice before changing option names (possibly breaking scripts out there). 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] (no subject)
Hi Michai, On 28 February 2015 at 01:44, Michai Ramakers wrote: > I'll pick this one up. Did you mean to change the actual option-names too? No, that was probably a mistake and my misunderstanding of the comments vs. options. What do you recommend regarding option names? It's easier to type checkin but easier to read check-in. Thanks for your other recommendation, by the way. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] (no subject)
On 27 February 2015 at 21:17, jungle Boogie wrote: > > Attached is a list of all, what I believe are comments, from src/*.c > that contain checkin. I'm assuming these are diffs against trunk tip of the time of writing, but perhaps next time it's useful to mention the checkin/check-in version against which the diff was made. 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] (no subject)
On 27 February 2015 at 21:17, jungle Boogie wrote: > > Attached is a list of all, what I believe are comments, from src/*.c > that contain checkin. I'll pick this one up. Did you mean to change the actual option-names too? Help will be regenerated after a recompile, after a change in corresponding comment-sections in source-files. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] (no subject)
Hello All,
Attached is a list of all, what I believe are comments, from src/*.c
that contain checkin.
Can this be updated to check-in as we are graduating from checkin?
If these lines are updated, does that mean /help will also be updated, too?
--
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
src/add.c:628:** can be made at the next commit/checkin.
src/browse.c:878:** SQL used to compute the age of all files in checkin :ckin
whose
src/browse.c:918:** mtime on that checkin. If zGlob and *zGlob then only files
matching
src/browse.c:992:** name=VERSION Selects the checkin version (default=tip).
src/bundle.c:184:** Identify a subsection of the checkin tree using
command-line switches.
src/bundle.c:191:** --checkin TAGCheckin TAG only
src/bundle.c:268:**--checkin TAG The subtree is the single
checkin TAG
src/bundle.c:289:** --checkin TAG
src/bundle.c:746:** described by the --branch, --from, --to, and/or
--checkin options,
src/bundle.c:752:** --checkin TAG Package the single
checkin TAG
src/bundle.c:783:** --checkin TAG Use
only checkin TAG
src/checkin.c:1500:**--tag TAG-NAME assign given tag TAG-NAME
to the checkin
src/checkin.c:1874: ** which would work for this checkin. The first
manifest (held
src/checkin.c:1972:** calculated before the checkin started (and stored as
the R record
src/db.c:1662:**--date-override DATETIME use DATETIME as time of the
initial checkin
src/db.c:1663:** (default: do not create an
initial checkin)
src/descendants.c:35:** table consisting of leaves that are descended from a
single checkin.
src/descendants.c:296:** Find all leaf descendants of the checkin specified or
if the argument
src/descendants.c:297:** is omitted, of the checkin currently checked out.
src/diff.c:2214:**checkin=ID The manifest ID at which to start the
annotation
src/diff.c:2399:** who made each checkin and omits the line number.
src/doc.c:467:** Look for a file named zName in the checkin with RID=vid. Load
the content
src/foci.c:19:** files associated with a single checkin.
src/foci.c:35:** checkinIDINTEGER,-- RID for the checkin manifest
src/foci.c:38:** previousName TEXT, -- Name of the file in previous
checkin
src/fusefs.c:300:** in the checkin. If DIRECTORY does not exist, then an
attempt is
src/fusefs.c:304:** do "ls DIRECTORY/checkins" to get a listing of all possible
checkin
src/fusefs.c:305:** names. There are countless variations on checkin names and
it is
src/graph.c:368: ** A merge parent is a prior checkin from which changes were
merged into
src/import.c:787:** checkin then xbranch.brnm is the branch that checkin is
part of.
src/info.c:884:** Find an checkin based on query parameter zParam and parse its
src/info.c:1644:** Attempt to lookup the specified checkin and file name into
an rid.
src/leaf.c:21:** The LEAF table contains the rids for all leaves in the checkin
DAG.
src/leaf.c:22:** A leaf is a checkin that has no children in the same branch.
src/leaf.c:106:** Check to see if checkin "rid" is a leaf and either add it to
the LEAF
src/manifest.c:683: ** checkin historically has an empty P-card, so empty
P-cards
src/manifest.c:705: ** this checkin ("+") or backed out of this checkin
("-").
src/manifest.c:1000:** Given a checkin name, load and parse the manifest for
that checkin.
src/path.c:354:** Compute all file name changes that occur going from checkin
iFrom
src/path.c:355:** to checkin iTo.
src/publish.c:64:** instance of that branch are included, not just the most
recent checkin.
src/purge.c:200:** Check to see if any checkin in zTab is a baseline manifest
for some
src/purge.c:223:** The TEMP table named zTab contains the RIDs for a set of
checkin
src/search.c:19:** against timeline comments, checkin content, wiki pages,
and/or tickets.
src/tar.c:450:** Given the RID for a checkin, construct a tarball containing
src/tar.c:451:** all files in that checkin
src/tar.c:587:** Generate a compressed tarball for a checkin.
src/th_main.c:275:** Attempt to lookup the specified checkin and file name into
an rid.
___
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] (no subject)
At Sat, 30 Aug 2014 09:57:21 +0200, Stephan Beal wrote: > > [1 ] > [1.1 ] > > [1.2 ] > On Sat, Aug 30, 2014 at 8:41 AM, Stephan Beal wrote: > > Out of curiosity's sake, i went ahead and used the various existing > pieces to create a standalone > mini-timeilne application (to see if any needed parts are missing). It's > entire implementation: > > And here it is with file listing support (the query for that is more than > half the script): > > http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/timeline.s2 > I do want to reimplement the timeline view at some point, so this may prove useful. Good to know that s2 is capable of doing this task. Tim ___ 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] (no subject)
On Sat, Aug 30, 2014 at 8:41 AM, Stephan Beal wrote: > Out of curiosity's sake, i went ahead and used the various existing pieces > to create a standalone mini-timeilne application (to see if any needed > parts are missing). It's entire implementation: > And here it is with file listing support (the query for that is more than half the script): http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/timeline.s2 [stephan@host:~/cvs/fossil/libfossil/s2]$ ./timeline.s2 -- -files checkin 5760ed07f8 @ 2014-08-30 07:49:11 by stephan more work on the fsl/db/repo-related modules, added basic timeline app impl in s2. File UUID Size Name modified cf89296325948 s2/require.d/fsl/db/repo.s2 addede98a662a0f557 s2/require.d/fsl/db/repoOrCheckout.s2 added36d477a597 2624 s2/timeline.s2 ... the app is based off of a require.js-like model, and the storage for the scripts (e.g. filesystem vs db vs compiled into the C code) is abstracted away from the user. This makes it possible to use the various pieces of that in both CLI or CGI apps (or anything in between, for that matter, though there are not many words in between CG and CL ;). -- - 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] (no subject)
On Sat, Aug 30, 2014 at 6:46 AM, Stephan Beal wrote:
> You do now :). The first script-available feature was the DB layer. It
> seems i didn't bind the pseudo-recursive transactions bits, but everything
> else one needs for DB access seems to be there, and the require.s2 module
> makes it really easy to write mini-apps/modules to import data:
>
Out of curiosity's sake, i went ahead and used the various existing pieces
to create a standalone mini-timeilne application (to see if any needed
parts are missing). It's entire implementation:
#!/usr/bin/env f-s2sh
assert Fossil.require;
Fossil.require(
['fsl/db/checkout', // opens the current checkout
'fsl/timeline/basic' // array of recent event table entries
],
proc(co,tl){
const j2h = Fossil.time.julianToHuman;
const fmt = "%1$-8s %2$.10s @ %3$s by %4$s";
const typeMap = { // maps event.type labels to strings
g: 'tag', w: 'wiki',
ci: 'checkin', e: 'event',
t: 'ticket'
};
tl.eachIndex(proc(v){
print(fmt.applyFormat(typeMap[v.type]|||'???',
v.uuid,
j2h(v.mtime),
v.user));
print('\t',v.comment);
});
});
which outputs:
[stephan@host:~/cvs/fossil/libfossil/s2]$ ./timeline.s2
checkin b9d3c27a12 @ 2014-08-30 06:25:15 by stephan
latest s2/requires2.
checkin 7a4fa849d3 @ 2014-08-27 18:47:25 by stephan
latest s2, added missing require.s2 scripts.
tag 3c78d1c612 @ 2014-08-26 21:21:11 by stephan
Edit [0f48e69758f241506f43bb4c6370baef0ef09f5a|0f48e69758]: Edit check-in
comment.
checkin 0f48e69758 @ 2014-08-26 21:20:23 by stephan
latest s2, lots of little stuff, one notable corner-case bug (bogus OOM
error).
checkin acc01d60c7 @ 2014-08-26 17:26:53 by stephan
accommodated API changes.
--
- 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] (no subject)
At Sat, 30 Aug 2014 06:46:28 +0200, Stephan Beal wrote: > > [1 ] > [1.1 ] > > [1.2 ] > On Sat, Aug 30, 2014 at 5:59 AM, Timothy Beyer wrote: > > foo LIKE '%BAR%' > > I believe that there is some sort of issue with the way the % symbol is > handled. > > When passing anything via URLs, '%' needs to be encoded as %25 - it's a > special HTTP character. I tried that encoding previously, but it only worked in some cases. I don't remember the specifics. I'll gather the examples that didn't work as soon as I find where I notated them. :) Regards, Tim ___ 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] (no subject)
On Sat, Aug 30, 2014 at 5:59 AM, Timothy Beyer wrote: > foo LIKE '%BAR%' > > I believe that there is some sort of issue with the way the % symbol is > handled. > When passing anything via URLs, '%' needs to be encoded as %25 - it's a special HTTP character. If you pass the query string via POST, that won't happen. Whereas the following works correctly: > > foo GLOB '*[Bb][Aa][Rr]*' > Because those aren't special HTTP characters (need no encoding). > I've been meaning to submit patches, but I haven't even looked at that > part of > the code yet, and you probably know it much better than I do. > A report is fine - i don't mind doing the patching. i think this is a case of not encoding, though. > Thanks for the JSON API, it's been invaluable. > :) > That sounds very promising. My issues with TH1 were namely that I didn't > know > how to use it in dynamic AJAX type applications, (to start with, I think > the > TH1 argv API was deprecated, am I correct in this assumption?) You can't use th1 in ajax apps because fossil has no mechanism for doing so (e.g. for specifying a custom Content-Type and replacing all output of the page). In fact, that's how this all started... Two summers ago i tried to extend fossil with the ability to add "custom pages," which were just scripts which could do whatever you like (e.g. create JSON responses instead of a web page). It turned out th1 wasn't up for the job, which became the catalyst for two things: (A) finally sitting down and working on the garbage collector i'd been thinking through for several years, with the intention being working towards a scripting engine, and (B) libfossil, because any client-extensible scriptability needs a library-style API (something we had discussed at the project level before, but discounted because of the effort required). It took a year to get the initial scripting engine and language (two separate beasts) in place, at which point libfossil was started (Summer, 2013), and the second script engine was started this past June to replace the first one (which had grown kind of crufty in its brief life). and that I > couldn't access parts of the database that were crucial to my needs. You do now :). The first script-available feature was the DB layer. It seems i didn't bind the pseudo-recursive transactions bits, but everything else one needs for DB access seems to be there, and the require.s2 module makes it really easy to write mini-apps/modules to import data: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/artifact/09965598835e943b617e84fab83d3b2f49bbc9a7 (One might notice that i adopted tcl's proc keyword, as it's just so much simpler to type than function!) require.s2 is here: https://docs.google.com/document/d/14gRP4f-WWgWNS64KM_BI7YjQqBLl4WT3jIrmNmFefYU/view I'll look > into libfossil at some point, as I find fossil the ideal basis for > applications > based on a versioned datastore. > One of libfossil's goals is to allow one to plug those same features into arbitrary applications. It can currently do quite a bit (most of the read-only features and many of the writing ones), but some of the critical features are still missing, namely merge/update and anything network related. I like TCL and especially TK, so I see a lot of potential in TH1, but it > seems > to me that JavaScript is already an ideal extension language for most > fossil-based web applications. > TCL isn't much my cup of tea, but i'm in the minority on that point around here ;). s2's JS-like syntax is just what i happen to find most comfortable to use. It can, however, be more syntactically verbose than command-based languages like TCL, and TCL's style is arguably a closer fit to fossil(1), though whether that's true for fossil(3) remains to be seen. Maybe we'll have a TCL binding on libfossil at some point (the s2 bindings are not built-in to libfossil - they're essentially a 3rd-party application). > Those permssions are for a reason - imagine what happens if a user sends > "DROP TABLE blob" via the > > JSON API. Even if we use authenticators which prohibit that (sqlite > supports it), being able to query > > allows them to reach _any_ blob, regardless of access restrictions. > > I figured that was the reason, and it's perfectly legitimate, but I just > wish > that there was some way to block all JSON API URLs from outside of the > fossil > repository, only allowing it to be used in the application itself. > Once a query has arrived, there's no way to know where it came from. The JSON API, for example, can be used from the CLI as well as via HTTP (because it's much easier to test that way). It can figure out whether it's running from the CLI, but it seems too limiting to me to restrict queries to that mode. Two potential solutions, used in conjunction, come to mind: a) maybe a repo-level config option which says whether to allow SELECT queries from anyone with (say) checkin access. b) install sqlite authenticators via the JSON API
Re: [fossil-users] (no subject)
At Fri, 29 Aug 2014 08:33:13 +0200, Stephan Beal wrote: > > [1 ] > [1.1 ] > > [1.2 ] > On Fri, Aug 29, 2014 at 4:59 AM, Timothy Beyer wrote: > > There are some limitations that we worked around, such as the fact that > the "%" > symbol has a lot of bugs when used in JSON SQL queries (thus making most > wildcard matches with LIKE useless), so I use GLOB with a regular > expression > for case-insensitivity. > > If you can post some examples i'd be happy to take a look at fixing them. > Hi Stephan, Sorry about the delayed response. I'll get specific queries that failed next week, but as a summary, queries like the following have issues in JSON URLs: foo LIKE '%BAR%' I believe that there is some sort of issue with the way the % symbol is handled. Whereas the following works correctly: foo GLOB '*[Bb][Aa][Rr]*' I've been meaning to submit patches, but I haven't even looked at that part of the code yet, and you probably know it much better than I do. Thanks for the JSON API, it's been invaluable. > th1 is extremely limited. libfossil is developing more powerful script > bindings: > > https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view That sounds very promising. My issues with TH1 were namely that I didn't know how to use it in dynamic AJAX type applications, (to start with, I think the TH1 argv API was deprecated, am I correct in this assumption?) and that I couldn't access parts of the database that were crucial to my needs. I'll look into libfossil at some point, as I find fossil the ideal basis for applications based on a versioned datastore. I like TCL and especially TK, so I see a lot of potential in TH1, but it seems to me that JavaScript is already an ideal extension language for most fossil-based web applications. > Those permssions are for a reason - imagine what happens if a user sends > "DROP TABLE blob" via the > JSON API. Even if we use authenticators which prohibit that (sqlite supports > it), being able to query > allows them to reach _any_ blob, regardless of access restrictions. I figured that was the reason, and it's perfectly legitimate, but I just wish that there was some way to block all JSON API URLs from outside of the fossil repository, only allowing it to be used in the application itself. Regards, Tim ___ 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] (no subject)
On Fri, Aug 29, 2014 at 9:11 AM, Joe Mistachkin
wrote:
> It would be _much_ easier now. My view is this: I view TH1 purely as an
>
avenue to access Fossil-specific commands and expose them to Tcl, period.
> If I wanted to do serious custom script development with Fossil, almost
> all of the "TH1" scripts would look something like:
>tclEval {
>
# invoke a TH1 command...
> th1Eval [list trace "starting Tcl script"]
>
If that provides me with at least line/column info (filename when including
multiple files), then i'm happy. Plus points for stack traces ;). (IIRC
JimTCL can do those.)
i looked into adding line/col info to th1 early on, but just didn't see how
to get it into those structures.
--
- 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] (no subject)
Stephan Beal wrote:
>
> No offense intended,
>
I'm not offended. I'm just weary.
>
> but try developing a 1000-lins script which fails on line 743 with the
> sole message "syntax error." That's exceedingly limiting for someone
> who isn't intimately familiar with that code, and often painful for
> someone who is.
>
Agreed, the error handling is sub-optimal.
>
> i tried using th1 to implement fully custom fossil /pages two summers
> ago, even went so far as to extract th1 into a standalone lib.
>
It would be _much_ easier now. My view is this: I view TH1 purely as an
avenue to access Fossil-specific commands and expose them to Tcl, period.
If I wanted to do serious custom script development with Fossil, almost
all of the "TH1" scripts would look something like:
tclInvoke set repository_name [repository 1]
tclEval {
# invoke a TH1 command...
th1Eval [list trace "starting Tcl script"]
# query some TH1 state via a command...
set magicParam [th1Eval [list getParameter magicParam]]; # param...
# do more stuff here...
# optionally access the repository database...
package require sqlite3
sqlite3 db $repository_name -readonly true
th1Eval [list trace "done with Tcl script"]
}
--
Joe Mistachkin
___
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] (no subject)
On Fri, Aug 29, 2014 at 8:42 AM, Joe Mistachkin wrote: > Stephan Beal wrote: > > > > th1 is extremely limited. libfossil is developing more powerful script > bindings: > > > > I'm growing more than a bit tired of this "meme". > No offense intended, but try developing a 1000-lins script which fails on line 743 with the sole message "syntax error." That's exceedingly limiting for someone who isn't intimately familiar with that code, and often painful for someone who is. i tried using th1 to implement fully custom fossil /pages two summers ago, even went so far as to extract th1 into a standalone lib. Development of scripts is, however, too painful. TH1 been enhanced, extended, and it can integrate seamlessly with full Tcl > rather > easily (i.e. when the right compile-time and runtime options are enabled). > Maybe it's useful via that route, but th1 by itself cannot be used for scripts of any really appreciable complexity, at least not by anyone who doesn't posses supernatural levels of patience. -- - 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] (no subject)
Stephan Beal wrote: > > th1 is extremely limited. libfossil is developing more powerful script bindings: > I'm growing more than a bit tired of this "meme". TH1 been enhanced, extended, and it can integrate seamlessly with full Tcl rather easily (i.e. when the right compile-time and runtime options are enabled). Also, there are now full command and web page hooks. The necessary compile-time options are: FOSSIL_ENABLE_TCL=1 FOSSIL_ENABLE_TH1_HOOKS=1 The necessary runtime options are: tcl (boolean) th1-hooks (boolean) More useful settings are: th1-uri-regexp (versionable) th1-setup (versionable) tcl-setup (versionable) -- Joe Mistachkin ___ 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] (no subject)
On Fri, Aug 29, 2014 at 4:59 AM, Timothy Beyer wrote: > There are some limitations that we worked around, such as the fact that > the "%" > symbol has a lot of bugs when used in JSON SQL queries (thus making most > wildcard matches with LIKE useless), so I use GLOB with a regular > expression > for case-insensitivity. > If you can post some examples i'd be happy to take a look at fixing them. > Further, TH1 is very limited, so even in the case of static SQL queries, > you > th1 is extremely limited. libfossil is developing more powerful script bindings: https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view > I find it annoying that users have to be an "Administrator" or "Super > User" to > access the JSON api for SQL queries, as I'd like to choose which tables > they are able to query or not, but then again, it is a distributed version > control > system, so it probably doesn't make sense to have fine-grained security in > the > first place. > Those permssions are for a reason - imagine what happens if a user sends "DROP TABLE blob" via the JSON API. Even if we use authenticators which prohibit that (sqlite supports it), being able to query allows them to reach _any_ blob, regardless of access restrictions. -- - 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] (no subject)
At Thu, 28 Aug 2014 11:42:58 -0400, Todd Niec wrote: > > [1 ] > [1.1 ] > > [1.2 ] > Hi, > > I am new to fossil as well as this list, so I apologize if this posting is > off-topic, answered > elsewhere, or inappropriate in any way. > > I am looking at using fossil as a low-footprint, "off-line" > bug-tracking/ticketing system. At work I am developing a ticketing system that non-programmers will use internally, with no modifications to fossil itself. If you have similar needs to our company, you will make heavy use of the JSON API and JavaScript to get the right UI widgets, and to get things customized in a way that non-developers will use the software (one issue that they complained about in particular was the existence of the "View Ticket" page). I implemented full search capabilities, many new input widgets, among other things, so it is very flexible. There are some limitations that we worked around, such as the fact that the "%" symbol has a lot of bugs when used in JSON SQL queries (thus making most wildcard matches with LIKE useless), so I use GLOB with a regular expression for case-insensitivity. Further, TH1 is very limited, so even in the case of static SQL queries, you may still need to use SQL through the JSON API, because queries within TH1 arbitrarily prohibit many tables (I did a look up on the list of logins for a multi-select form, for example). I find it annoying that users have to be an "Administrator" or "Super User" to access the JSON api for SQL queries, as I'd like to choose which tables they are able to query or not, but then again, it is a distributed version control system, so it probably doesn't make sense to have fine-grained security in the first place. Regards, Tim ___ 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] (no subject)
Thanx for the info. Adding the check out permission did the trick but it does seem a little counterintuitive that a user would have permission to check out but not to clone ;} I also apologize for the second question, I had left a sentence out and ending up asking the wrong question. But anyway thank you Richard for your answer, it confirms that my intended course of action is the right one. What I wanted to ask was whether or not it is possible with the latest version of Fossil to use MarkDown in the description field of a ticket. If it is possible, then where could I find some documentation on how to configure Fossil so that this capability can be activated? Sorry for the confusion. . . :: paul On Aug 28, 2014, at 16:02 , Ron W wrote: > On Thu, Aug 28, 2014 at 6:46 PM, Paul Higham wrote: > With the developer permissions set the attachments can be downloaded (a .pdf > will open directly in the browser, but an Excel document is actually > downloaded) but with all the permissions that I gave below even the .pdf is > inaccessible. The project manager that I mentioned does not need a local > copy of the repository, all he needs is to be able to create, edit and view > tickets and their attachments on the repository that sits on an AWS ‘cloud’. > So I still don’t know which is the operative permission flag or is it simply > not possible to do what I am trying to do in Fossil? > > I think check out is needed to download attachments and check in needed to > upload. > > (To my thinking, ticket attachments should not require check in/out. If > people feel the existing ticket specific permissions should not grant > attachment privs, then maybe consider adding addition perms to Fossil.) > > I plan on updating the cloud version of Fossil but I do have the latest on my > own machine. However, I cannot find any specific instructions even on the > Fossil website as to how to do this. Is it possible or not? > > Do what? Update Fossil in your AWS instance? > > Assuming you want Fossil server to auto-start on boot, you update the Fossil > executable the same as on a physical PC in your possession, then you need to > save your / partition by creating a custom system image (I forget what AWS > calls these) then, from your AWS console, configure your instance to boot > from the new system image. > > Hopefully AWS instance configuration and custom system image creation is > easier than it used to be. It has been years since I ran an instance on AWS, > so I can't really say much about how to do stuff on it, but everything I > needed to do was documented back then, so I would expect it to be, now. > (Hopefully not wishful thinking.) > > ___ > 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] (no subject)
On Thu, Aug 28, 2014 at 7:02 PM, Ron W wrote:
> On Thu, Aug 28, 2014 at 6:46 PM, Paul Higham wrote:
>
>> With the developer permissions set the attachments can be downloaded (a
>> .pdf will open directly in the browser, but an Excel document is actually
>> downloaded) but with all the permissions that I gave below even the .pdf is
>> inaccessible. The project manager that I mentioned does not need a local
>> copy of the repository, all he needs is to be able to create, edit and view
>> tickets and their attachments on the repository that sits on an AWS
>> ‘cloud’. So I still don’t know which is the operative permission flag or
>> is it simply not possible to do what I am trying to do in Fossil?
>>
>
> I think check out is needed to download attachments and check in needed to
> upload.
>
>
Looking at the code (
http://www.fossil-scm.org/fossil/artifact/82ab7ae8506c?ln=153-159) it
appears that read-wiki permission ("j") is required to read attachments on
wiki pages and read-ticket permission ("r") is required to read attachments
to tickets.
For uploading attachments (
http://www.fossil-scm.org/fossil/artifact/82ab7ae8506c?ln=248-256) it looks
like you need both attach-permission ("b") and on of append-wiki ("m") or
append-ticket ("c") depending on whether the attachment is going onto a
wiki page or a ticket.
--
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] (no subject)
On Thu, Aug 28, 2014 at 6:46 PM, Paul Higham wrote: > > I plan on updating the cloud version of Fossil but I do have the latest on > my own machine. However, I cannot find any specific instructions even on > the Fossil website as to how to do this. Is it possible or not? > > (1) Put the new fossil binary on the server (2) Run "fossil rebuild $REPO" for each of your repositories (3) There is no step 3. You are done. The second step can normally be accomplished by running "fossil all rebuild" but your version of fossil is so old that it might not have recorded the locations of all the repositories and so the "all" command might not work for you. Safer, I think, to simply run "fossil rebuild $REPO" for each repository. -- 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] (no subject)
On Thu, Aug 28, 2014 at 6:46 PM, Paul Higham wrote: > With the developer permissions set the attachments can be downloaded (a > .pdf will open directly in the browser, but an Excel document is actually > downloaded) but with all the permissions that I gave below even the .pdf is > inaccessible. The project manager that I mentioned does not need a local > copy of the repository, all he needs is to be able to create, edit and view > tickets and their attachments on the repository that sits on an AWS > ‘cloud’. So I still don’t know which is the operative permission flag or > is it simply not possible to do what I am trying to do in Fossil? > I think check out is needed to download attachments and check in needed to upload. (To my thinking, ticket attachments should not require check in/out. If people feel the existing ticket specific permissions should not grant attachment privs, then maybe consider adding addition perms to Fossil.) > I plan on updating the cloud version of Fossil but I do have the latest on > my own machine. However, I cannot find any specific instructions even on > the Fossil website as to how to do this. Is it possible or not? > Do what? Update Fossil in your AWS instance? Assuming you want Fossil server to auto-start on boot, you update the Fossil executable the same as on a physical PC in your possession, then you need to save your / partition by creating a custom system image (I forget what AWS calls these) then, from your AWS console, configure your instance to boot from the new system image. Hopefully AWS instance configuration and custom system image creation is easier than it used to be. It has been years since I ran an instance on AWS, so I can't really say much about how to do stuff on it, but everything I needed to do was documented back then, so I would expect it to be, now. (Hopefully not wishful thinking.) ___ 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] (no subject)
With the developer permissions set the attachments can be downloaded (a .pdf will open directly in the browser, but an Excel document is actually downloaded) but with all the permissions that I gave below even the .pdf is inaccessible. The project manager that I mentioned does not need a local copy of the repository, all he needs is to be able to create, edit and view tickets and their attachments on the repository that sits on an AWS ‘cloud’. So I still don’t know which is the operative permission flag or is it simply not possible to do what I am trying to do in Fossil? I plan on updating the cloud version of Fossil but I do have the latest on my own machine. However, I cannot find any specific instructions even on the Fossil website as to how to do this. Is it possible or not? :: paul On Aug 28, 2014, at 11:34 , Stephan Beal wrote: > On Thu, Aug 28, 2014 at 7:42 PM, Paul Higham wrote: > I want to grant permission to a project manager here to be able to create, > edit and view tickets and their attachments, but I don’t want him to be able > to clone, check in or check out. > i don't believe that complete combo is possible (someone else may correct > me). You can lock down clone and checkin, but a checkout works on his local > clone/copy, so you cannot restrict that. > > > I have given him all the following permissions: bcdefhjkmnprtuw but he still > cannot access attachments - does anyone know which is the right permission > flag? BTW the Fossil version used on the server is 1.24 [f60a86d0f2] > 2012-10-30 15:49:26 > > Ancient! That needs to be updated. > > Is it possible to use MarkDown in Fossil ticket descriptions? My problem is > that the limited capabilities of the wiki markup is preventing enthusiastic > acceptance of Fossil by some of the non-developers at my (very small) company. > i _think_ it is, but possibly not with your version. MD was added sometime > around that timeframe, IIRC, but might not be in that version. > > -- > - 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 ___ 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] (no subject)
On Thu, Aug 28, 2014 at 7:42 PM, Paul Higham wrote: > >- I want to grant permission to a project manager here to be able to >create, edit and view tickets and their attachments, but I don’t want him >to be able to clone, check in or check out. > > i don't believe that complete combo is possible (someone else may correct me). You can lock down clone and checkin, but a checkout works on his local clone/copy, so you cannot restrict that. > >- I have given him all the following permissions: bcdefhjkmnprtuw but >he still cannot access attachments - does anyone know which is the >right permission flag? BTW the Fossil version used on the server is 1.24 >[f60a86d0f2] 2012-10-30 15:49:26 > > Ancient! That needs to be updated. > >- Is it possible to use MarkDown in Fossil ticket descriptions? My >problem is that the limited capabilities of the wiki markup is preventing >enthusiastic acceptance of Fossil by some of the non-developers at my (very >small) company. > > i _think_ it is, but possibly not with your version. MD was added sometime around that timeframe, IIRC, but might not be in that version. -- - 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] (no subject)
I have questions regarding two subjects that have been mentioned in this thread: I want to grant permission to a project manager here to be able to create, edit and view tickets and their attachments, but I don’t want him to be able to clone, check in or check out. I have given him all the following permissions: bcdefhjkmnprtuw but he still cannot access attachments - does anyone know which is the right permission flag? BTW the Fossil version used on the server is 1.24 [f60a86d0f2] 2012-10-30 15:49:26 Is it possible to use MarkDown in Fossil ticket descriptions? My problem is that the limited capabilities of the wiki markup is preventing enthusiastic acceptance of Fossil by some of the non-developers at my (very small) company. Thanx for any help in these regards. :: paul On Aug 28, 2014, at 09:17 , Ron W wrote: > On Thu, Aug 28, 2014 at 11:42 AM, Todd Niec wrote: > It seems to fit the bill almost perfectly, but I cannot enter formatted > descriptions in the tickets. I am losing my whitespace formatting, for > example. I see there is a drop-down list with choices like "wiki", and HTML > but that does not seem let me format the entry. > > > > Am I missing something? > > > I know you can enable (Fossil) wiki formatting in tickets, probably also > MarkDown formatting (never tried it, don't use MarkDown). And a subset of > HTML is also accepted. > > When you do, you have to follow the formatting rules. For example, wiki > paragraph breaks require a blank line between the paragraphs. In HTML, a > paragraph is surrounded by and . HTML also allows line breaks: . > > See http://fossil-scm.org/index.html/wiki_rules for how to do this. > > ___ > 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] (no subject)
On Thu, Aug 28, 2014 at 11:42 AM, Todd Niec wrote: > > It seems to fit the bill almost perfectly, but I cannot enter formatted > descriptions in the tickets. I am losing my whitespace formatting, for > example. I see there is a drop-down list with choices like "wiki", and > HTML but that does not seem let me format the entry. > > > > Am I missing something? > I know you can enable (Fossil) wiki formatting in tickets, probably also MarkDown formatting (never tried it, don't use MarkDown). And a subset of HTML is also accepted. When you do, you have to follow the formatting rules. For example, wiki paragraph breaks require a blank line between the paragraphs. In HTML, a paragraph is surrounded by and . HTML also allows line breaks: . See http://fossil-scm.org/index.html/wiki_rules for how to do this. ___ 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] (no subject)
On Thu, Aug 28, 2014 at 11:42 AM, Todd Niec wrote: > Hi, > > > > I am new to fossil as well as this list, so I apologize if this posting is > off-topic, answered elsewhere, or inappropriate in any way. > > > > I am looking at using fossil as a low-footprint, "off-line" > bug-tracking/ticketing system. > > > > It seems to fit the bill almost perfectly, but I cannot enter formatted > descriptions in the tickets. I am losing my whitespace formatting, for > example. I see there is a drop-down list with choices like "wiki", and > HTML but that does not seem let me format the entry. > > > > Am I missing something? > > > > I guess there is one other thing I would want in a ticket system, that is > the ability to attach files to tickets. Is that possible? > > > All of that is possible, but it will require some tweaking of the ticket setup for your repo. Sadly, our documentation on how to do that is sub-par - its something we need to work on. If you would like to contribute to the documentation, your contributions will be most welcomed! If you spend a little time and get the ticket system configured the way you want it, then write a brief article titled something like "How A Newbie Configured Fossil's Tickets To Do What He Wanted" I sure it will be much appreciated by others in your situation. And if you encounter insurmountable difficulties, you can always get help here on this mailing list. And we (the developers) are likely to add features if you discover missing capabilities. If you come up with an interesting ticket setup, maybe we can add it as a "one-click" setup option someplace so that others can use it without the hassle and learning curve. -- 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] (no subject)
On Thu, Aug 28, 2014 at 5:46 PM, Stephan Beal wrote: > That sounds like a but to me. i'll see if i can reproduce it here, but i > don't do much with the ticket system and don't have an immediate suspect in > mind. > i can't reproduce that using the current trunk (or very close to it): http://fossil.wanderinghorse.net/tmp/fossil-ticket-format.png that was done using the "plain text" format. Notice the "attach" submenu - that apparently only appears after saving the ticket once. Can you give us more info about what you're doing? -- - 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] (no subject)
On Thu, Aug 28, 2014 at 5:42 PM, Todd Niec wrote: > I am new to fossil as well as this list, so I apologize if this posting is > off-topic, answered elsewhere, or inappropriate in any way. > Welcome aboard! > I am looking at using fossil as a low-footprint, "off-line" > bug-tracking/ticketing system. > > > > It seems to fit the bill almost perfectly, but I cannot enter formatted > descriptions in the tickets. I am losing my whitespace formatting, for > example. I see there is a drop-down list with choices like "wiki", and > HTML but that does not seem let me format the entry. > > > > Am I missing something? > That sounds like a but to me. i'll see if i can reproduce it here, but i don't do much with the ticket system and don't have an immediate suspect in mind. > I guess there is one other thing I would want in a ticket system, that is > the ability to attach files to tickets. Is that possible? > Yes - somewhere in the ticket editor is the option to attach files. -- - 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
[fossil-users] (no subject)
Hi, I am new to fossil as well as this list, so I apologize if this posting is off-topic, answered elsewhere, or inappropriate in any way. I am looking at using fossil as a low-footprint, "off-line" bug-tracking/ticketing system. It seems to fit the bill almost perfectly, but I cannot enter formatted descriptions in the tickets. I am losing my whitespace formatting, for example. I see there is a drop-down list with choices like "wiki", and HTML but that does not seem let me format the entry. Am I missing something? I guess there is one other thing I would want in a ticket system, that is the ability to attach files to tickets. Is that possible? thanks Todd Niec Chief Technical Officer Tornado Technologies, Inc. 30275 Bainbridge Rd Building A, Suite 5 Solon OH 44139 Office: (216) 454-4000 x115 Cell: (216) 454-4000 x215 Backup: (216) 978-9746 ___ 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] (no subject)
I reran ./configure, make clean, make and things look good on my end now too. Apologies for the noise. -bch On 4/29/13, Richard Hipp wrote: > On Mon, Apr 29, 2013 at 7:25 PM, Richard Hipp wrote: > >> >> >> On Mon, Apr 29, 2013 at 6:55 PM, B Harder wrote: >> >>> Fossil trunk [748f975345] generates a binary that immediate segfaults. >>> My env is: >>> >>> NetBSD kamloops 6.99.19 NetBSD 6.99.19 (GENERIC) #149: Mon Apr 29 >>> 11:57:00 PDT 2013 >>> root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 >>> >> >> Works fine for me on Mac, Windows, and Linux and on Linux under valgrind. >> Curious to know what the problem is on NetBSD... >> >> > The website is now running the very latest Fossil. No issues noted. > > The ticket malfunction is because yesterday I did a "fossil rebuild" using > an older version of Fossil, which change the TICKET table back to an older > format. Rebuilding tickets with an up-to-date Fossil easily fixed that. > > -- > D. Richard Hipp > d...@sqlite.org > -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] (no subject)
On Mon, Apr 29, 2013 at 7:25 PM, Richard Hipp wrote: > > > On Mon, Apr 29, 2013 at 6:55 PM, B Harder wrote: > >> Fossil trunk [748f975345] generates a binary that immediate segfaults. >> My env is: >> >> NetBSD kamloops 6.99.19 NetBSD 6.99.19 (GENERIC) #149: Mon Apr 29 >> 11:57:00 PDT 2013 >> root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 >> > > Works fine for me on Mac, Windows, and Linux and on Linux under valgrind. > Curious to know what the problem is on NetBSD... > > The website is now running the very latest Fossil. No issues noted. The ticket malfunction is because yesterday I did a "fossil rebuild" using an older version of Fossil, which change the TICKET table back to an older format. Rebuilding tickets with an up-to-date Fossil easily fixed that. -- 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] (no subject)
Thx for the test drh. I'll see what I can on my end. On 4/29/13, Richard Hipp wrote: > On Mon, Apr 29, 2013 at 6:55 PM, B Harder wrote: > >> Fossil trunk [748f975345] generates a binary that immediate segfaults. >> My env is: >> >> NetBSD kamloops 6.99.19 NetBSD 6.99.19 (GENERIC) #149: Mon Apr 29 >> 11:57:00 PDT 2013 >> root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 >> > > Works fine for me on Mac, Windows, and Linux and on Linux under valgrind. > Curious to know what the problem is on NetBSD... > > -- > D. Richard Hipp > d...@sqlite.org > -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] (no subject)
On Mon, Apr 29, 2013 at 6:55 PM, B Harder wrote: > Fossil trunk [748f975345] generates a binary that immediate segfaults. > My env is: > > NetBSD kamloops 6.99.19 NetBSD 6.99.19 (GENERIC) #149: Mon Apr 29 > 11:57:00 PDT 2013 > root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 > Works fine for me on Mac, Windows, and Linux and on Linux under valgrind. Curious to know what the problem is on NetBSD... -- 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
[fossil-users] (no subject)
Fossil trunk [748f975345] generates a binary that immediate segfaults. My env is: NetBSD kamloops 6.99.19 NetBSD 6.99.19 (GENERIC) #149: Mon Apr 29 11:57:00 PDT 2013 root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64 I haven't had a change to triage this yet, and fossil's ticket system is also currently broken, so I couldn't file a ticket. -bch -- Brad Harder Method Logic Digital Consulting http://twitter.com/bcharder ___ 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] (no subject)
So I don't quite remember what you've tried, and the summary below doesn't have the whole chain, so please forgive me if this has been covered or you are aware of the difference. You're using "fossil update A" not "fossil checkout A" between branches, right? If i remember, "checkout" (or "co") traverses the entire tree, because it simply deletes what's in the current checkout and replaces it with a fresh version. "update" only deals with changes. Or some such difference. Again, sorry if I've misunderstood you! Tomek From: follow...@yahoo.com Date: Mon, 8 Oct 2012 20:20:15 +0800 To: davidr...@googlemail.com CC: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] (no subject) I have tried it.It still traverse every file, though they are the same in the two branches. On 2012-10-8, at 17:30, David Bariod wrote: On Wed, Oct 3, 2012 at 2:02 PM, J Ronald wrote: For example, there is a checkin node A with a lot of source code files, then make a branch B from A with a little modification, also make a branch C from A with a little modification. The structure is like this: B C \ / A Then checkin every thing, it is very slow to switch between B & C, it seems to check every file in A when switching. You may try to change the default settings for this repository. fossil settings repo-cksum off This should speed up your checkout operations. -- David Bariod ___ 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] (no subject)
I have tried it. It still traverse every file, though they are the same in the two branches. On 2012-10-8, at 17:30, David Bariod wrote: > > > On Wed, Oct 3, 2012 at 2:02 PM, J Ronald wrote: >> For example, there is a checkin node A with a lot of source code files, >> >> then make a branch B from A with a little modification, >> >> also make a branch C from A with a little modification. >> >> The structure is like this: >> >> B C >> >> \ / >> >>A >> >> Then checkin every thing, it is very slow to switch between B & C, it seems >> to check every file in A when switching. > > > You may try to change the default settings for this repository. > fossil settings repo-cksum off > This should speed up your checkout operations. > > -- > David Bariod > ___ 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] (no subject)
On Wed, Oct 3, 2012 at 2:02 PM, J Ronald wrote: > For example, there is a checkin node A with a lot of source code files, > > then make a branch B from A with a little modification, > > also make a branch C from A with a little modification. > > The structure is like this: > > B C > > \ / > >A > > Then checkin every thing, it is very slow to switch between B & C, it > seems to check every file in A when switching. > You may try to change the default settings for this repository. fossil settings repo-cksum off This should speed up your checkout operations. -- David Bariod ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] (no subject)
For example, there is a checkin node A with a lot of source code files, then make a branch B from A with a little modification, also make a branch C from A with a little modification. The structure is like this: B C \ / A Then checkin every thing, it is very slow to switch between B & C, it seems to check every file in A when switching.___ 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] (no subject)
.Add some spice to your sex! Its the first step to change your life! http://listadoweb.com/com.friend.php?latlink_friend_id=58q2 ___ 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] (no subject)
Hi, I can't run it on 1.6, what java version did you compile with? Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at jurassic.GUI2.configureApplicationMenu(GUI2.java:478) at jurassic.GUI2$4.run(GUI2.java:303) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) Petr On Tue, Nov 23, 2010 at 12:40, markovi...@inwind.it wrote: > Hi, > I've release a new version of Fossil GUI Jurassic (0.3.0). > > New user interface with office-ish ribbon (with tickets and wikis). > Fixed the DAG upside-down problem. > > Discuss: http://groups.google.com/group/jurassic-fossil > > Download: http://code.google.com/p/jurassic-fossil/ > > Enjoy! > > ___ > 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
[fossil-users] (no subject)
Hi, I've release a new version of Fossil GUI Jurassic (0.3.0). New user interface with office-ish ribbon (with tickets and wikis). Fixed the DAG upside-down problem. Discuss: http://groups.google.com/group/jurassic-fossil Download: http://code.google.com/p/jurassic-fossil/ Enjoy! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
