Re: [fossil-users] cmd line support for tickets

2010-10-07 Thread wolfgang
Eric e...@... writes:

  :
 Most native English speakers would not even have thought of using
 fieldslist, and it sounds odd. I think fieldlist is correct, though I
 might have chosen
 
 fossil ticket fields
 
 depending on the rest of the possible syntax.
 
 Regards,
 
 Eric
 

What about changing

  fossil fieldlist

into

  fossil list fields

and adding

  fossil list reports

This way, a gui can offer a dropdown of available reports and the commands
read more like english sentences :-)

best regards
Wolfgang



___
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] cmd line support for tickets

2010-10-07 Thread Ramon Ribó
It sounds very nice !!

-RR



2010/10/7 Wolfgang rat...@stumvolls.de:
 Eric e...@... writes:

   :

 fossil ticket fields

 depending on the rest of the possible syntax.

   :
 With checkin 3f06f272cd , i changed it to

 fossil ticket list fields

 and added

 fossil ticket list reports

 All commands can be shortend, f.e. fossil l f is valid!

 best regards
 Wolfgang



 ___
 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] cmd line support for tickets

2010-10-07 Thread wolfgang
Christian Busch busch.christ...@... writes:

 
 One more idea for the fossil ticket add  ...:
 Is it possible to print a command with the UUID of the new ticket?
 
 -Christian
  :

I think, i'll should print a protocoll message like 

  ticket UUID changed/added/add failed/update failed

to stdout after commands add/set. This is no problem and i'll add it.

best regards
Wolfgang

___
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] cmd line support for tickets

2010-10-07 Thread Eric

 Eric e...@... writes:

:

 fossil ticket fields

 depending on the rest of the possible syntax.

:
 With checkin 3f06f272cd , i changed it to

 fossil ticket list fields

 and added

 fossil ticket list reports

 All commands can be shortend, f.e. fossil l f is valid!


I assume you mean

fossil tic l f

(because of timeline and tag)

E

___
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] cmd line support for tickets

2010-10-07 Thread Wolfgang
Eric e...@... writes:
 
  All commands can be shortend, f.e. fossil l f is valid!
 
 
 I assume you mean
 
 fossil tic l f
 
 (because of timeline and tag)
 
 E
 

You are right, i was foccused on implementing the ticket command, so
i've forgotten to name it in the command line :-(

best regards
Wolfgang


___
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] cmd line support for tickets

2010-10-07 Thread Wolfgang
Wolfgang rat...@... writes:

:
 With checkin 3f06f272cd , i changed it to 
 
 fossil ticket list fields
 
 and added 
 
 fossil ticket list reports
 
 All commands can be shortend, f.e. fossil l f is valid!
 

The command is merged into the trunk.

= Ramdebugger can learn to fly, using ticket reports,.. .

best regards
Wolfgang


___
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] cmd line support for tickets

2010-10-06 Thread Ramon Ribó
 Hello,

 This new version looks very nice to be used by a GUI. A couple of comments:

1-  fossil.exe ticket list

Would it be better something like?:

fossil.exe ticket fieldlist

Or similar? fossil ticket list looks like it is going to list all tickets

 2- A proposal of small changes for the help:

  Run the the ticket report, identified by the report format title
   used in the gui. The data is written as flat file on stdout,
   using , as rows separator. The separator , can be changed using
   the -l or --limit option.
   If TICKETFILTER is given on the commandline, the query is
   limited with a new WHERE-condition.
 example:  Report lists a column # with the uuid
   TICKETFILTER may be [#]='u'
 example:  Report only lists rows with status not open
   TICKETFILTER: status != 'open'
   If the option -q|--quote is used, the tickets are encoded by
   quoting special chars(space - \s, tab - \t, newline - \n,
   cr - \r, formfeed - \f, vtab - \v, nul - \0, \ - \\).
   Otherwise, the simplified encoding as on the show report raw
   page in the gui is used.

  Anyway, thanks for the addition to fossil. This new feature looks
very nice and will be useful for automated GUI's. I hope that it will
be moved soon to the trunk

RR



2010/10/5 wolfgang rat...@stumvolls.de:
 Ramon Ribó ram...@... writes:


  In the newest version, you can call the report by its name

 This is nice, but I was meaning that it was difficult for me to
 understand the help text. Maybe, it is difficult for someone else too.

 OK, i've changed the default. I'm describing the title first. The number is
 added as advanced feature.

    1- ...
 
  This doesn't help, because after reconfiguring, the columns in the gui do
  not match the report, though it has the correct name.
 
    2- ...
 
  You don't know the table structure and so you cannot give a correct aql
  statement.
 
    3- ...
 
  This would work

 Neither of the 3 solutions will work for ALL ticket configurations.
 However, I am sure that they will give meaningful results for 95% of
 the fossil repositories out there. And this is enough for a
 standardized GUI. If someone defines a ticket without status field
 or with strange fields, then he is not going to use the commodity
 mechanism offered by the GUI for dealing with the tickets. They will
 continue doing it by hand as they do it now.

 I'll add a special report number 0, which lists all columns, defined in the
 table. THis report can be used by a gui, the filter can be given as last
 argument in the form status'fixed' and 
 What about the encoding of tickets.

 I don't want to hard code a special column(status) in the sources. Fossil is
 fully configurable and this shouldn't be changed.

 Quoting the output:
 I don't think, it's neccessary to define a special row limiter. Each ticket
 will be written on one line. I'll add an option to select between to encodings
 of tickets:
 1. the actually implemented version, which uses the same algorithm as the raw
   option on the show report page (usefull for a quick look by humans)
 2. The fossil internal coding of special chars(space - \s, tab - \t,
   newline - \n, cr - \r, formfeed - \f, vtab - \v, nul - \0, \ - \\).
   This can easily be parsed with standard limiter tab(useful for linking 
 guis).

 The actual help text is listed below. If you have a proposal for a better,
 feel free to send it to me.

 E:\test 19:52:20,35 fossil help ticket
 Usage: fossil.exe ticket SUBCOMMAND ...

 Run various subcommands to control tickets

    fossil.exe ticket show (REPORTTITLE|REPORTNR) ?TICKETFILTER? ?options?

        options can be:
          ?-l|--limit LIMITCHAR?
          ?-q|--quote?

        Run the the ticket report, identified by the report title
        used in the gui. The data is written as flat file on stdout,
        using , as separator. The seperator , can be changed using
        the -l or --limit option.
        If TICKETFILTER is given on the commandline, the query is
        limited with a new WHERE-condition.
          example:  Report lists a column # with the uuid
                    TICKETFILTER may be [#]='u'
        If the option -q|--quote is used, the tickets are encoded by
        quoting special chars(space - \s, tab - \t, newline - \n,
        cr - \r, formfeed - \f, vtab - \v, nul - \0, \ - \\).
        Otherwise, the simplified encoding as on the show report raw
        page in the gui is used.

        Instead of the report title its possible to use the report
        number. Using the special report number 0 list all columns,
        defined in the ticket table.

    fossil.exe ticket list

        list all columns, defined in the ticket table

    fossil.exe ticket set TICKETUUID FIELD VALUE ?FIELD VALUE ... ?

        change ticket identified by TICKETUUID and set the value of
        field FIELD to VALUE. Valid field descriptions are:

Re: [fossil-users] cmd line support for tickets

2010-10-06 Thread Wolfgang
Ramon Ribó ram...@... writes:
  :
  This new version looks very nice to be used by a GUI. A couple of comments:
 
 1-  fossil.exe ticket list
 
 Would it be better something like?:
 
 fossil.exe ticket fieldlist

I've changed the command to fieldlist

 
  2- A proposal of small changes for the help:
 

I added your changes.

In addition to your proposals, i've added an option -q to add/set. So a gui
can add complex texts to the fields.

I think, the ticket command has reached a final state and can be tested/added
in a gui framework or more complex batch framework. If you don't have the build
environment and if you need a windows executable, feel free to give me a note.

best regards
Wolfgang

___
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] cmd line support for tickets

2010-10-06 Thread Ramon Ribó
Nice work.

what is your opinion between these two alternatives:?

fossil.exe ticket fieldlist

fossil.exe ticket fieldslist




Compass Ing. y Sistemas         Dr. Ramon Ribo
http://www.compassis.com      ram...@compassis.com
c/ Tuset, 8 7-2                          tel. +34 93 218 19 89
08006 Barcelona, Spain            fax. +34 93 396 97 46



2010/10/6 Wolfgang rat...@stumvolls.de:
 Ramon Ribó ram...@... writes:
  :
  This new version looks very nice to be used by a GUI. A couple of comments:

 1-  fossil.exe ticket list

     Would it be better something like?:

     fossil.exe ticket fieldlist

 I've changed the command to fieldlist


  2- A proposal of small changes for the help:


 I added your changes.

 In addition to your proposals, i've added an option -q to add/set. So a gui
 can add complex texts to the fields.

 I think, the ticket command has reached a final state and can be tested/added
 in a gui framework or more complex batch framework. If you don't have the 
 build
 environment and if you need a windows executable, feel free to give me a note.

 best regards
 Wolfgang

 ___
 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] cmd line support for tickets

2010-10-06 Thread Wolfgang
Ramon Ribó ram...@... writes:

 
 what is your opinion between these two alternatives:?
 
 fossil.exe ticket fieldlist
 
 fossil.exe ticket fieldslist
 


I prefer the first on, but this might be influenced by my native 
language - german.

A quick google search finds more fieldlist than fieldslist entries, so i
tend to use fieldlist.

best regards
Wolfgang

___
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] cmd line support for tickets

2010-10-06 Thread Ramon Ribó
 A quick google search finds more fieldlist than fieldslist entries, so i
 tend to use fieldlist.

Then, if we have google veredict, it should be definitive!!!

RR

2010/10/6 Wolfgang rat...@stumvolls.de:
 Ramon Ribó ram...@... writes:


 what is your opinion between these two alternatives:?

 fossil.exe ticket fieldlist

 fossil.exe ticket fieldslist



 I prefer the first on, but this might be influenced by my native
 language - german.

 A quick google search finds more fieldlist than fieldslist entries, so i
 tend to use fieldlist.

 best regards
 Wolfgang

 ___
 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] cmd line support for tickets

2010-10-06 Thread Eric
On Wed, October 6, 2010 at 12:25 pm, Wolfgang rat...@stumvolls.de wrote:
 Ramon Ribó ram...@... writes:


 what is your opinion between these two alternatives:?

 fossil.exe ticket fieldlist

 fossil.exe ticket fieldslist



 I prefer the first on, but this might be influenced by my native
 language - german.

 A quick google search finds more fieldlist than fieldslist entries, so i
 tend to use fieldlist.

 best regards
 Wolfgang

Most native English speakers would not even have thought of using
fieldslist, and it sounds odd. I think fieldlist is correct, though I
might have chosen

fossil ticket fields

depending on the rest of the possible syntax.

Regards,

Eric

___
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] cmd line support for tickets

2010-10-05 Thread Wolfgang
Christian Busch busch.christ...@... writes:

  :
 Will fossil have a kind of api or cmd line support for the ticket system 
 in some future?
 
 The inverse problem will appear as well. Having all this tickets in 
 fossil, I'd like to extract the information in some report format.
  :

Hi

On branch wolfgangTicket with checkin 9d3b9d653a you'll find a first version,
supporting show/add/set commands for tickets. The built in help text is shown
below.

I think it should fulfill most requirements, even linking an external gui to
the fossil application

E:\testfossil help ticket
Usage: fossil.exe ticket SUBCOMMAND ...

Run various subcommands to control tickets

fossil.exe ticket show REPORTNR ?TICKETFILTER? ?-l|--limit LIMITCHAR?

Run the the ticket report, identified by the report number
used in the gui. The data is written as flat file on stdout,
using , as separator. The seperator , can be changed using
the -l or --limit option.
If TICKETFILTER is given on the commandline, the query is
limited with a new WHERE-condition.
  example:  Report lists a column # with the uuid
TICKETFILTER= [#]='u'

fossil.exe ticket set FIELD VALUE ?FIELD VALUE ... ? TICKETUUID

change ticket identified by TICKETUUID and set the value of
field FIELD to VALUE. Valid field descriptions are:
   status, type, severity, priority, resolution,
   foundin, private_contact, resolution, title or comment
Field names given above are the ones, defined in a standard
fossil environment. If you have added, deleted columns, you
change the all your configured columns.
You can use more than one field/value pair on the commandline.

fossil.exe ticket add FIELD VALUE ?FIELD VALUE ... ?

like set, but create a new ticket with the given values.
 




___
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] cmd line support for tickets

2010-10-05 Thread Ramon Ribó
    fossil.exe ticket show REPORTNR ?TICKETFILTER? ?-l|--limit LIMITCHAR?

What is REPORTNR?


 I think it should fulfill most requirements, even linking an external gui to
 the fossil application

How do you list all tickets that are not closed or fixed, with its
basic data of:
TICKETUUID,title,status ?

RR



2010/10/5 Wolfgang rat...@stumvolls.de:
 Christian Busch busch.christ...@... writes:

  :
 Will fossil have a kind of api or cmd line support for the ticket system
 in some future?

 The inverse problem will appear as well. Having all this tickets in
 fossil, I'd like to extract the information in some report format.
  :

 Hi

 On branch wolfgangTicket with checkin 9d3b9d653a you'll find a first version,
 supporting show/add/set commands for tickets. The built in help text is shown
 below.

 I think it should fulfill most requirements, even linking an external gui to
 the fossil application

 E:\testfossil help ticket
 Usage: fossil.exe ticket SUBCOMMAND ...

 Run various subcommands to control tickets

    fossil.exe ticket show REPORTNR ?TICKETFILTER? ?-l|--limit LIMITCHAR?

        Run the the ticket report, identified by the report number
        used in the gui. The data is written as flat file on stdout,
        using , as separator. The seperator , can be changed using
        the -l or --limit option.
        If TICKETFILTER is given on the commandline, the query is
        limited with a new WHERE-condition.
          example:  Report lists a column # with the uuid
                    TICKETFILTER= [#]='u'

    fossil.exe ticket set FIELD VALUE ?FIELD VALUE ... ? TICKETUUID

        change ticket identified by TICKETUUID and set the value of
        field FIELD to VALUE. Valid field descriptions are:
           status, type, severity, priority, resolution,
           foundin, private_contact, resolution, title or comment
        Field names given above are the ones, defined in a standard
        fossil environment. If you have added, deleted columns, you
        change the all your configured columns.
        You can use more than one field/value pair on the commandline.

    fossil.exe ticket add FIELD VALUE ?FIELD VALUE ... ?

        like set, but create a new ticket with the given values.





 ___
 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] cmd line support for tickets

2010-10-05 Thread wolfgang
Ramon Ribó ram...@... writes:

  :
     fossil.exe ticket show REPORTNR ?TICKETFILTER? ?-l|--limit LIMITCHAR?
 
 What is REPORTNR?
 
  I think it should fulfill most requirements, even linking an external gui to
  the fossil application
 
 How do you list all tickets that are not closed or fixed, with its
 basic data of:
 TICKETUUID,title,status ?
  :

The reportnumber is the internal id of reports, defined on the tickets
page(reportlist). You'll find a list of valid reports, each uses an internal
number, which can be seen as argument rn in the URL, if you call this report.

Maybe i'll add the ability, to call the list with the report name. 

Because the ticket table can be configured, we cannot use a 'standard report',
because we do not know, which names we have to use, to generate a standard
report, as the one, you mentioned.

If you want such an report, you have to define it inside fossil. Take a look at
the reports, defined at fossil-scm.org. You can add the WHERE-condition to the
report definition, so you don't have to filter it when calling the fossil
ticket show command. For the original fossil-scm repository, the report 2 / all
open tickets should match your requirements.

best regards
Wolfgang

___
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] cmd line support for tickets

2010-10-05 Thread Wolfgang
Ramon Ribó ram...@... writes:

 
   Hi,
 
   It was not easy for me to discover that REPORTNR refers to one of
 the report formats listed in the Tickets main menu page. I would
 explain it more detailed in the help, maybe using REPORT_FORMAT_NUMBER
 instead of REPORTNR

In the newest version, you can call the report by its name :-)

   At the same time, as the result of this command is a table, there
 should be two delimiters instead of one. One for the rows and another
 one for the columns. Also, what to do when the delimiter character is
 contained in one of the fields? Maybe you should check the CSV format
 for ideas.

Currently i'm using a function, already defined in the report source. Newlines
and spaces are compressed in this variant. Quoting of the separators(strings!)
is not implemented yet.

I can add a secong option for line separators. If this is used, i could
activate the separator quoting.

   Another problem is that this solution is not adequate for an
 automatic GUI that should be useful for any fossil database. The GUI
 cannot create automatically a new report format without user
 permission and new fossil databases only contain by default the report
 All Tickets.
 
   I see three solutions here:
 
   1- All new fossil databases contain, by default, a report with name
 All open tickets (then, the new command should permit to select it
 by name)

This doesn't help, because after reconfiguring, the columns in the gui do
not match the report, though it has the correct name.

   2- The SQL for the report is embedded in the fossil command

You don't know the table structure and so you cannot give a correct aql
statement.

   3- Add a special subcommand:
 
  fossil.exe ticket list -status Open fieldList ?-l|--limit LIMITCHAR?

This would work
 
  This command only works for tickets that have a status field.
 If a tickets table does not have the status field, nothing is
 returned.

The mapping should be configured in the gui.

I'll take a look, how to implement a fully quoting report output and i'll
add the list columns command.




___
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] cmd line support for tickets

2010-10-05 Thread Christian Busch
  Hi.
I've compiled:
This is fossil version [63d91f0b87] 2010-10-05 16:37:40 UTC

I've to do further tests, but at the moment it looks great.

Thanks.
Christian

Am 05.10.2010 20:22, schrieb wolfgang:
 Ramon Ribóram...@...  writes:

 In the newest version, you can call the report by its name
 This is nice, but I was meaning that it was difficult for me to
 understand the help text. Maybe, it is difficult for someone else too.
 OK, i've changed the default. I'm describing the title first. The number is
 added as advanced feature.

1- ...
 This doesn't help, because after reconfiguring, the columns in the gui do
 not match the report, though it has the correct name.

2- ...
 You don't know the table structure and so you cannot give a correct aql
 statement.

3- ...
 This would work
 Neither of the 3 solutions will work for ALL ticket configurations.
 However, I am sure that they will give meaningful results for 95% of
 the fossil repositories out there. And this is enough for a
 standardized GUI. If someone defines a ticket without status field
 or with strange fields, then he is not going to use the commodity
 mechanism offered by the GUI for dealing with the tickets. They will
 continue doing it by hand as they do it now.
 I'll add a special report number 0, which lists all columns, defined in the
 table. THis report can be used by a gui, the filter can be given as last
 argument in the form status'fixed' and 
 What about the encoding of tickets.

 I don't want to hard code a special column(status) in the sources. Fossil is
 fully configurable and this shouldn't be changed.

 Quoting the output:
 I don't think, it's neccessary to define a special row limiter. Each ticket
 will be written on one line. I'll add an option to select between to encodings
 of tickets:
 1. the actually implemented version, which uses the same algorithm as the raw
 option on the show report page (usefull for a quick look by humans)
 2. The fossil internal coding of special chars(space -  \s, tab -  \t,
 newline -  \n, cr -  \r, formfeed -  \f, vtab -  \v, nul -  \0, \ - 
  \\).
 This can easily be parsed with standard limiter tab(useful for linking 
 guis).

 The actual help text is listed below. If you have a proposal for a better,
 feel free to send it to me.

 E:\test 19:52:20,35fossil help ticket
 Usage: fossil.exe ticket SUBCOMMAND ...

 Run various subcommands to control tickets

  fossil.exe ticket show (REPORTTITLE|REPORTNR) ?TICKETFILTER? ?options?

  options can be:
?-l|--limit LIMITCHAR?
?-q|--quote?

  Run the the ticket report, identified by the report title
  used in the gui. The data is written as flat file on stdout,
  using , as separator. The seperator , can be changed using
  the -l or --limit option.
  If TICKETFILTER is given on the commandline, the query is
  limited with a new WHERE-condition.
example:  Report lists a column # with the uuid
  TICKETFILTER may be [#]='u'
  If the option -q|--quote is used, the tickets are encoded by
  quoting special chars(space -  \s, tab -  \t, newline -  \n,
  cr -  \r, formfeed -  \f, vtab -  \v, nul -  \0, \ -  \\).
  Otherwise, the simplified encoding as on the show report raw
  page in the gui is used.

  Instead of the report title its possible to use the report
  number. Using the special report number 0 list all columns,
  defined in the ticket table.

  fossil.exe ticket list

  list all columns, defined in the ticket table

  fossil.exe ticket set TICKETUUID FIELD VALUE ?FIELD VALUE ... ?

  change ticket identified by TICKETUUID and set the value of
  field FIELD to VALUE. Valid field descriptions are:
 status, type, severity, priority, resolution,
 foundin, private_contact, resolution, title or comment
  Field names given above are the ones, defined in a standard
  fossil environment. If you have added, deleted columns, you
  change the all your configured columns.
  You can use more than one field/value pair on the commandline.

  fossil.exe ticket add FIELD VALUE ?FIELD VALUE ... ?

  like set, but create a new ticket with the given values.

 The values in set|add are not validated against the definitions
 given in the Ticket Common Script.


 ___
 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] cmd line support for tickets

2010-10-04 Thread Richard Hipp
On Mon, Oct 4, 2010 at 4:25 AM, Christian Busch busch.christ...@gmx.dewrote:

  Hi all,

 I'm evaluating fossil as a scm for the developement of testing software
 for embedded system testing. There will be a huge amount of  test
 scripts and after a test run there might be a lot of found problems in
 the test scripts. I'd like to issue tickets for all found 'open points'
 in the test scripts with a generated batch script.

 Will fossil have a kind of api or cmd line support for the ticket system
 in some future?


Since tickets are configurable on a site-by-site basis, I is difficult to
imagine what a command-line interface to the ticketing system might look
like.  Do you have any suggestions?  Since I do not, clearly there are no
current plans to add such a thing.



 The inverse problem will appear as well. Having all this tickets in
 fossil, I'd like to extract the information in some report format.


Fossil lets you generate custom reports based on SQL queries of the ticket
database.



 Thanks for your response/discussion.

 Regards,
 Christian
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
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] cmd line support for tickets

2010-10-04 Thread Ramon Ribó
 Since tickets are configurable on a site-by-site basis, I is difficult to
imagine
 what a command-line interface to the ticketing system might look like.  Do
you  have any suggestions?

Yes, I do.

I've developed a GUI for fossil (inside RamDebugger), that permits to select
an open ticket and add its id and comment to the current commit. It would be
nice if the user could, at the same time, mark the ticket as Closed or
Fixed.

So, It would be enough for this application to have the possibility of
changing the status of the ticket.

It would be also nice to have a more ordered list of tickets with its id,
comment and status so as to avoid parsing fossil timeline -t t

RR


2010/10/4 Richard Hipp d...@sqlite.org



 On Mon, Oct 4, 2010 at 4:25 AM, Christian Busch busch.christ...@gmx.dewrote:

  Hi all,

 I'm evaluating fossil as a scm for the developement of testing software
 for embedded system testing. There will be a huge amount of  test
 scripts and after a test run there might be a lot of found problems in
 the test scripts. I'd like to issue tickets for all found 'open points'
 in the test scripts with a generated batch script.

 Will fossil have a kind of api or cmd line support for the ticket system
 in some future?


 Since tickets are configurable on a site-by-site basis, I is difficult to
 imagine what a command-line interface to the ticketing system might look
 like.  Do you have any suggestions?  Since I do not, clearly there are no
 current plans to add such a thing.



 The inverse problem will appear as well. Having all this tickets in
 fossil, I'd like to extract the information in some report format.


 Fossil lets you generate custom reports based on SQL queries of the ticket
 database.



 Thanks for your response/discussion.

 Regards,
 Christian
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




 --
 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] cmd line support for tickets

2010-10-04 Thread wolfgang
Ramon Ribó ram...@... writes:
   :
 So, It would be enough for this application to have the possibility of
changing the status of the ticket.
 
 It would be also nice to have a more ordered list of tickets with its id,
comment and status so as to avoid parsing fossil timeline -t t
 RR2010/10/4 Richard Hipp d...@sqlite.org
 On Mon, Oct 4, 2010 at 4:25 AM, Christian Busch
busch.christ...@gmx.de wrote:
 
   :
Hello

I understand your requirements as follows:

1. fossil ticket set (status|type|severity|priority|resolution) value
   the problem is, that the allowed values are defined using th-script.
2. fossil ticket list report-number
   export the data, shown on the corresponding gui ticket report page, as
   simple text export(csv). By using the report definition mechanismen, we
   have full flexibility for reports and consistency with the gui.
   This shouldn't be a problem.

I would implement it, if we can get a common sense about the things to do.

best regards
Wolfgang



___
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] cmd line support for tickets

2010-10-04 Thread wolfgang
Christian Busch busch.christ...@... writes:

 
   That's looking perfect for me!
 I was about to require the add-comand, because this is the first thing 
 I would need. Also the ability of checking and adding own defined 
 field-value pairs would be very helpful.
 
 Anybody has further ideas to add?
 
   :

With checkin [f3f7f13815] on branch wolfgangTicketCmd i've started a
ticket program.

Until now, i implemented the show command - without filter UUID option.
All other commands are only mentioned in the help not implemented.

If i understand
 .. Also the ability of checking and adding own defined 
 field-value pairs would be very helpful.
as i want to edit the values of an existing/new ticket , this will be
possible with my proposal. It you're thinking about adding new columns
to the ticket table, i would say no. Configuring the columns of the
ticket table needs to change more than one setting in fossil's
admin/ticket page. So this should only be done inside the gui.

best regards
Wolfgang

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users