Hi All,
I've implemented the fossiltag command in the th1_fossiltag_cmd
branch. I opted not to implement
a command to get at settings since sensitive information is likely to
be present.
Usage for the fossiltag command is described inline in the comments,
and I'll duplicate it here for easy reading.
My hope is that this will provide the beginnings some useful
integration points for automated testing facilities and QA
departments. See the example given for the 'get' subcommand for an
idea.
I've also pushed the th1_wikicontent_cmd branch, for posterity, and in
case anyone else wants to use it.
/*
** TH1 command: fossiltag list|get ...
**
** Provide TH1 commands for read-only interation with tags on
** any taggable artifact. The tags are always raw.
**
*/
...
/*
**
** TH1 command: fossiltag list ?ARTIFACT-ID?
**
** Returns a list of tags on ARTIFACT-ID. Or, all tags,
** if ARTIFACT-ID is not specified. Only uncancelled tags
** are included in the result.
**
** Example:
** <b>List of tags on thing:</b>
** <th1>
** puts [fossiltag list 2b4630f34]
** </th1>
*/
...
/*
**
** TH1 command: fossiltag get TAG-NAME ?ARTIFACT-ID? ?FALLBACK-VALUE?
**
** Returns the value of TAG-NAME on ARTIFACT-ID, or
** one of the following:
** if FALLBACK-VALUE provided and TAG-NAME not present,
** then FALLBACK-VALUE is returned.
** if FALLBACK-VALUE not provided, and TAG-NAME not present,
** then 0 returned.
** if TAG-NAME present, but has no value, then 1 is returned.
**
** Example:
** <b>Check-in acceptance status:</b>
** <th1>
** set accept_out ""
** if {[set out [fossiltag get "QA_acceptance" $check_in_id
"<b>DID NOT PASS</b>"]]} {
** set accept_out " * QA: ${out}"
** }
** if {[set out [fossiltag get "Unit_passed" $check_in_id "<b>DID
NOT PASS UNIT TESTS</b>"]]} {
** set accept_out "${accept_out}\n * Unit tests: ${out}"
** }
** if {[set out [fossiltag get "Signed_off_by" $check_in_id
"<b>NOT SIGNED OFF</b>"]]} {
** set accept_out "${accept_out}\n * Signed off by: ${out}"
** }
** puts [wiki $accept_out]
** </th1>
*/
On Thu, Oct 7, 2010 at 1:22 PM, Brian Smith <[email protected]> wrote:
> On Thu, Oct 7, 2010 at 1:37 AM, Wolfgang <[email protected]> wrote:
>> Brian Smith <br...@...> writes:
>>
>> :
>>> TH1 usage: 'wikicontent WIKIPAGE_NAME FALLBACK_TEXT'
>>>
>>> The command returns the contents of a wiki page (presently, only real
>>> wiki pages, not embedded docs),
>>> or FALLBACK_TEXT, if the page doesn't exist.
>>>
>> :
>>
>> This is an interisting idea, but for me, it's somhow an abuse of wiki pages.
>>
>> I would prefer an extension of the settings dialogs. I would add a new
>> settings
>> page, which uses own user priviledges and so we could assign the priviledges
>> as
>> we need it. The new settings page should offer the ability to add name/value
>> pairs as user defined settings.
>> This pairs can be stored in the settings table as 'USER_<name>' to
>> distinguished
>> from fossil standard settings.
>>
>> Then a TH-script function like
>>
>> TH1 usage: 'fossilsetting SETTINGNAME FALLBACK'
>>
>> would solve your problems and can be used for user defined and standard
>> settings.
>>
>
> I actually considered something similar but discarded it since adding
> a new privilege seems
> somewhat like bloat. I already find the privilege letters somewhat
> opaque. Adding another one
> is undesirable to me. Though, being able to get at arbitrary fossil
> settings via TH1 might be nice.
>
> I opted for the wiki page approach because they also already sync
> automatically, introducing a new thing
> such as the 'user settings' as you describe adds more to be synced.
>
> What might also suite me is to add a command to access fossil tags via
> TH1, then I could attach a tag, say, 'code-defect-template' with the
> content I want to the initial check-in, and then access it that way.
> And actually, that's somewhat closer to what I want anyway, since then
> only people with check-in ability can modify the template.
>
> What is everyone's feeling on adding two new TH1 commands: one to
> access settings, and one to access fossil tags?
>
> Usage would be something like:
>
> fossiltag TAG_NAME FALLBACK
>
> fossilsetting SETTING_NAME FALLBACK (as wolfgang described above)
>
> -B
>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
