On Fri, Sep 12, 2014 at 6:19 PM, Ron W ronw.m...@gmail.com wrote:
Nor does the JSON API need to handle things. Even the TH1 API doesn't
handle things. It's the code using the API that does the handling
Not if it comes to validation like length limits - that has to be done
C-side.
The
On Sat, Sep 13, 2014 at 4:29 AM, Stephan Beal sgb...@googlemail.com wrote:
That's where my problem (per se) is: handling new/update with
arbitrary/d field names is a huge pain in the butt in C. i'm completely
open to assisting someone else in doing it, but this particular problem is
not one
On Sat, Sep 13, 2014 at 11:07 AM, Ron W ronw.m...@gmail.com wrote:
Well then, it'll have to be SQL via either Fossil CLI or libfossil (or
DBD::SQLite).
But it's still C - the columns have to be transformed from JSON to SQL in
C. i admit - it's _not_ hard to do. All the pieces are there for
On Sat, Sep 13, 2014 at 5:25 AM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Sep 13, 2014 at 11:07 AM, Ron W ronw.m...@gmail.com wrote:
Well then, it'll have to be SQL via either Fossil CLI or libfossil (or
DBD::SQLite).
it's just tedious, which means that in order to get me to do
On Sat, Sep 13, 2014 at 7:16 PM, Ron W ronw.m...@gmail.com wrote:
Was never asking you to do it.
No, i know - sorry if i implied otherwise. i did feel like you were trying
to talk me into thinking about it, though ;). Some rainy day i might even
feel inspired to ;).
--
- stephan beal
On Sat, Sep 13, 2014 at 1:22 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Sep 13, 2014 at 7:16 PM, Ron W ronw.m...@gmail.com wrote:
Was never asking you to do it.
No, i know - sorry if i implied otherwise. i did feel like you were trying
to talk me into thinking about it, though
On Sat, Sep 13, 2014 at 3:38 PM, Joseph R. Justice jayare...@gmail.com
wrote:
From some Google searching, it looks as if libawk *might* have been a part
of the Gnu Arch (a.k.a. tla) version
...
Ah, and I've found another source for GNU Arch, and libawk, at
http://tla.sourcearchive.com/ .
On Thu, Sep 11, 2014 at 10:02 PM, Ron W ronw.m...@gmail.com wrote:
No different than my TH1 code being my responsibility to make sure it
handles my custom fields correctly.
handles is the operative word. TH1 can _handle_ things, and JSON, by
itself, cannot.
The only expectations of the
On Wed, Sep 10, 2014 at 1:23 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote:
Is it not possible to define an open-ended list of name-value pairs?
Sure we can, but then we've got a data format nobody can predict, which
doesn't
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit Ticket pages and associated TH1 apply the semantics correctly and
On Thu, Sep 11, 2014 at 1:14 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit
Does anyone have any experience with hooking up fossil to JIRA?
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Wed, Sep 10, 2014 at 9:26 AM, Eric Rubin-Smith eas@gmail.com wrote:
Does anyone have any experience with hooking up fossil to JIRA?
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
My
On Wed, Sep 10, 2014 at 6:12 PM, Ron W ronw.m...@gmail.com wrote:
like this could reasonably be accomplished with some combination of the
JSON API and the TCL integration.
And suggestions to either in order to make them usable for such purposes
are of course welcomed. :)
That said: ticket
Ron W wrote:
Does anyone have any experience with hooking up fossil to JIRA?
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
I guess I meant the former, though the latter is
Stephan Beal wrote:
That said: ticket integration with the JSON API turned out to be a lot
more work than anticipated (and thus it is quite castrated) because of
the customizability of the ticket subsystem and its close relationship to
the scripting world. Thus, i suspect, the TCL/TH1
As a separate question along those lines, have people had other sorts of
trouble (IT, data sanity or otherwise) with git+JIRA?
Sorry to self-reply. I meant for the sense of this question to be
constrained
specifically to the git-to-JIRA hooks or JIRA itself -- not to git as a
stand-alone
On Wed, Sep 10, 2014 at 12:21 PM, Stephan Beal sgb...@googlemail.com
wrote:
That said: ticket integration with the JSON API turned out to be a lot
more work than anticipated (and thus it is quite castrated) because of the
customizability of the ticket subsystem and its close relationship to
Stephan Beal wrote:
In principal, plain old transport is not the problem. The problem (as i
recall it, though it's been a while and i've got the memory of a goldfish)
was that i could not define a concrete structure for JSON/Ticket I/O
because tickets are customizable. Suggestions are
On Wed, Sep 10, 2014 at 6:44 PM, Eric Rubin-Smith eas@gmail.com wrote:
If we assume for a moment that the user is willing to customize the
Fossil ticket system to exactly match whatever is needed to integrate
with JIRA, does the problem become easy overall?
To answer that i'd need to
On Wed, Sep 10, 2014 at 6:35 PM, Ron W ronw.m...@gmail.com wrote:
But given that an integration with an external issue tracker would,
itself, have to be customisable, I am hoping that the JSON API can at least
transport the custom fields. If it were also possible to query the
On Wed, Sep 10, 2014 at 12:27 PM, Eric Rubin-Smith eas@gmail.com
wrote:
Ron W wrote:
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
I guess I meant the former, though the latter
On Wed, Sep 10, 2014 at 12:44 PM, Eric Rubin-Smith eas@gmail.com
wrote:
If we assume for a moment that the user is willing to customize the
Fossil ticket system to exactly match whatever is needed to integrate
with JIRA, does the problem become easy overall?
As I understand it, Jira is
On Wed, Sep 10, 2014 at 12:38 PM, Stephan Beal sgb...@googlemail.com
wrote:
In principal, plain old transport is not the problem. The problem (as i
recall it, though it's been a while and i've got the memory of a goldfish)
was that i could not define a concrete structure for JSON/Ticket I/O
On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote:
Is it not possible to define an open-ended list of name-value pairs?
i've forgotten the English word (and maybe there isn't one): jein
Sure we can, but then we've got a data format nobody can predict, which
doesn't sit well
25 matches
Mail list logo
