[fossil-users] New TH1 command: wikicontent

[Brian Smith]

Hi All,

Found that I had a need to prepopulate the 'new ticket comment' field
with a template.
I considered inlining the text directly into the template page and
using a conditional, but
found that didn't quite work for my purposes (namely, that I wanted
non-administators to be
able to edit the template, if needed).

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.

A quick round of comments and criticism would be great before
committing to the main repository.
Also attached is example usage in the context of the ticket new template page.

-B

  if {[info exists submit]} {
 set status Open
 submit_ticket
  }
  if {[string length $type]==0} {
 set type Code_Defect
  }



set comment [wikicontent ${type}_Template ${type}_Template]
set nline [linecount $comment 50 10]
$



wikicontent.patch
Description: Binary data
___
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] Patch file in windows

[Kyle McKay]

On Oct 6, 2010, at 05:10:29 PDT, Richard Hipp wrote:
> 2010/10/6 Lluís Batlle i Rossell 
> On Wed, Oct 06, 2010 at 12:39:15PM +0200, Emil Totev wrote:
> > Hello
> > This is fossil version [b48f78964e] 2010-09-18 15:51:43 UTC
> > on Windows XP SP3
> >
> > When I create a patch file using
> > fossil diff  > patch.txt
> >
> > the resulting file cannot be used for patching. It seems there is an
> > extra 0D line separator (0d 0d 0a) for the actual source lines.  
> (---,
> > +++, @@ lines are OK).
> >
> > The source files have normal Windows line endings, 0d 0a.
> I saw the same annoyance in fossil built for cygwin.
> I use "fossil diff | tr -d '\r'" to overcome that.
> You may also want to set a gdiff-tool, and use 'fossil gdiff', if  
> you have
> GNU diffutils available for example. I use that to get diffs in  
> unified format.
>
> Fossil is not taking any steps to insert extra CR characters in the  
> output.  The output of "fossil diff" is generated using printf().   
> Do you suppose that the windows implementation of printf() is trying  
> to be "helpful" by converting NL to CRNL?

Yup.  One of the "benefits" of using that OS.  The patch file must  
have been written in text mode.  Here are some references:



In addition to the above values, the following characters can be  
included in mode to specify the translation mode for newline characters:

t
Open in text (translated) mode. In this mode, CTRL+Z is interpreted as  
an end-of-file character on input. In files opened for reading/writing  
with "a+", fopen checks for a CTRL+Z at the end of the file and  
removes it, if possible. This is done because using fseek and ftell to  
move within a file that ends with a CTRL+Z, may cause fseek to behave  
improperly near the end of the file.

Also, in text mode, carriage return–linefeed combinations are  
translated into single linefeeds on input, and linefeed characters are  
translated to carriage return–linefeed combinations on output.







The stdin, stdout, and stderr streams always open in text mode by  
default; you can also override this default when opening any of these  
files. Use _setmode to change the translation mode using the file  
descriptor after the file is open.



--Kyle
___
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

[Eric]

On Wed, October 6, 2010 at 12:25 pm, "Wolfgang"  wrote:
> Ramon Ribó  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] bug in fossil mv

[Lluís Batlle i Rossell]

On Wed, Oct 06, 2010 at 11:26:01AM -0400, Wilson, Ronald wrote:
> Fossil undo doesn't work after a mv operation.  Also, I'm unable to move the 
> file back up the source tree because fossil thinks the path is outside of the 
> checkout tree.  I tried several variations.  Here is my repro:

I had the same problem and wanted to report about it. I end up doing "fossil
checkout", to save me from an unwanted 'mv' in the changes.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] bug in fossil mv

[Wilson, Ronald]

Fossil undo doesn't work after a mv operation.  Also, I'm unable to move the 
file back up the source tree because fossil thinks the path is outside of the 
checkout tree.  I tried several variations.  Here is my repro:


PS C:\rev\src\test> fossil ver
This is fossil version [7aae4ef068] 2010-09-03 01:57:41 UTC
PS C:\rev\src\test> fossil new ..\test.fossil
project-id: 642e99bc40ce3ba6e4b643dd79c1f8e14b55a645
server-id:  2fdbc1bdee11d946bba0105c34727630449caf84
admin-user: rwilso20 (initial password is "670296")
PS C:\rev\src\test> fossil open ..\test.fossil
PS C:\rev\src\test> ls


Directory: C:\rev\src\test


ModeLastWriteTime Length Name
- -- 
-a--- 10/6/2010  11:18 AM   7168 _FOSSIL_


PS C:\rev\src\test> echo 123 > x.txt
PS C:\rev\src\test> fossil add .\x.txt
ADDED  x.txt
PS C:\rev\src\test> fossil commit -m "1"
New_Version: aabc5e2eea1539d113322daa8a0395304c184a66
PS C:\rev\src\test> md sub


Directory: C:\rev\src\test


ModeLastWriteTime Length Name
- -- 
d 10/6/2010  11:20 AMsub


PS C:\rev\src\test> fossil mv .\x.txt sub
RENAME x.txt sub/x.txt
PS C:\rev\src\test> fossil undo
c:\rev\bin\fossil.exe: no update or merge operation is available to undo
PS C:\rev\src\test> move x.txt sub
PS C:\rev\src\test> fossil mv .\sub\x.txt .
c:\rev\bin\fossil.exe: file outside of checkout tree: .
PS C:\rev\src\test> fossil mv .\sub\x.txt .\
c:\rev\bin\fossil.exe: file outside of checkout tree: .\
PS C:\rev\src\test> fossil commit -m "2"
New_Version: 910c565be0c6b70c70a0725eba977abec16837b5
PS C:\rev\src\test> ls


Directory: C:\rev\src\test


ModeLastWriteTime Length Name
- -- 
d 10/6/2010  11:21 AMsub
-a--- 10/6/2010  11:24 AM211 manifest
-a--- 10/6/2010  11:24 AM 41 manifest.uuid
-a--- 10/6/2010  11:24 AM   8192 _FOSSIL_


PS C:\rev\src\test> fossil mv .\sub\x.txt .
c:\rev\bin\fossil.exe: file outside of checkout tree: .
PS C:\rev\src\test> fossil mv .\sub\x.txt .\
c:\rev\bin\fossil.exe: file outside of checkout tree: .\
PS C:\rev\src\test>

Ron Wilson, Engineering Project Lead
(o) 434.455.6453, (m) 434.851.1612, www.harris.com

___
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] Patch file in windows

[wolfgang]

Richard Hipp  writes:

   :
> > When I create a patch file using
> > fossil diff  > patch.txt
> >
> > the resulting file cannot be used for patching. It seems there is an
> > extra 0D line separator (0d 0d 0a) for the actual source lines. (---,
> > +++,  lines are OK).
> >
> > The source files have normal Windows line endings, 0d 0a.
> I saw the same annoyance in fossil built for cygwin.
> I use "fossil diff | tr -d '\r'" to overcome that.
> You may also want to set a gdiff-tool, and use 'fossil gdiff', if you have
> GNU diffutils available for example. I use that to get diffs in unified 
> format.
> 
> 
> Fossil is not taking any steps to insert extra CR characters in the output.
> The output of "fossil diff" is generated using printf().  Do you suppose that
> the windows implementation of printf() is trying to be "helpful" by converting
> NL to CRNL?   
> 
printf from standard c library does add an additional 0d, if:
  *  the file is opened as text
  *  the system uses 0d 0a as line break
  *  a 0a is written on stdout

So if we have a windows text file, stored in fossil including the 0d 0a's and
write multiple lines to stdout with a single printf("%s",...), each 0d 0a will
be written as 0d 0d 0a. The first 0d is from the original data, the second one
is inserted by printf.

The C library asumes, that text is internally stored only with \n as line
break. The 0d/0a vs 0d problem is solved during read/write, if files are opened
as text. I didn't check this, but i think, that fossil opens versioned files
binary, which is OK for creating correct diffs, but makes problems when
using simple printf-output.

___
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] Patch file in windows

[Richard Hipp]

2010/10/6 Lluís Batlle i Rossell 

> On Wed, Oct 06, 2010 at 12:39:15PM +0200, Emil Totev wrote:
> > Hello
> > This is fossil version [b48f78964e] 2010-09-18 15:51:43 UTC
> > on Windows XP SP3
> >
> > When I create a patch file using
> > fossil diff  > patch.txt
> >
> > the resulting file cannot be used for patching. It seems there is an
> > extra 0D line separator (0d 0d 0a) for the actual source lines. (---,
> > +++, @@ lines are OK).
> >
> > The source files have normal Windows line endings, 0d 0a.
> I saw the same annoyance in fossil built for cygwin.
> I use "fossil diff | tr -d '\r'" to overcome that.
> You may also want to set a gdiff-tool, and use 'fossil gdiff', if you have
> GNU diffutils available for example. I use that to get diffs in unified
> format.
>

Fossil is not taking any steps to insert extra CR characters in the output.
The output of "fossil diff" is generated using printf().  Do you suppose
that the windows implementation of printf() is trying to be "helpful" by
converting NL to CRNL?



>
> Regards,
> Lluís.
> ___
> 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] Using fossil before importing from svn

[Richard Hipp]

On Tue, Sep 28, 2010 at 11:24 PM, Clemens Hintze <
ml-fos...@qiao.in-berlin.de> wrote:

>
>
> Lluís Batlle i Rossell schrieb:
> > Hello,
>
> Hello Lluís,
>
> > we are going to try to switch from svn into fossil.
> >
> > As we could not find any tool ready to import svn history (even a single
> branch)
> > into fossil, I think that we are going to keep the svn history in its svn
> > repository, and we will start fossil from a last agreed point in the svn
> > history.
>
> I was already gone this way. I had also only imported one branch for of
> my SVN repository ...
>
> My solution was very primitive, but perhaps it does for you what you need.
>
> I have attached two files to this mail. One cat.sh and an XSLT stylesheet.
>
> For the XSLT stylesheet you need an XSLT processor. I used XML Starlet
> for that work, but others should work as well.
>
> Here is the receipt:
>
> 1. You should checkout the newest/last revision of the branch wou
>   want to import:
>
>   svn co http://.../my/project myproject
>
> 2. Put the script 'cat.sh' in the parent directory that contains the
>   checkedout project:
>
>   mv ./cat.sh .
>
> 3. Put the stylesheet 'svn2fsl.xsl' into the parent directory that
>   contains the checkeddout project:
>
>   mv ./svn2fsl.xsl .
>
> 4. 'cd' into the top directory of your project:
>
>   cd myproject
>
> 5. Create an empty Fossil repository and open it:
>
>   fsl new ../myproject.fossil
>

Maybe add the --date-override -MM-DD here, filling in a date that is
earlier than the earliest check-in of your SVN repository, so that the
initial empty Fossil checkin is correctly sequenced.



>   fsl open ../myproject.fossil
>
> 6. Create a first checkin (I am not sure, if this is still necessary):
>
>   echo "Initial empty checkin" > dummy_readme_txt
>   fsl add dummy_readme_txt
>   fsl ci -m "Initial empty import"
>
> 7. Generate and examine the import script:
>
>   svn log --xml | xml tr ../svn2fsl.xsl | tee  ../import_svn.sh
>
> 8. Import your SVN repository:
>
>   sh -x ../import_svn.sh
>
> This is, how I do remember my import I done over a year before. I hope I
> did not forgot anything, but I cannot warrant you. So please use it at
> yours own peril ...
>
> I hope it is of any use for you ...
>
>
> Best regards,
> chi.
>
> ___
> 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] performance on 'commit'

[Richard Hipp]

2010/10/6 Lluís Batlle i Rossell 

> Hello,
>
> we have a fossil repository of less than 100 commits, with a checkout of
> around
> 300MB, and around 3000 files.
>
> The fossil repository size is about 150MB.
>
> We notice that the 'fossil changes' command is very fast, but 'fossil
> commit'
> lasts for a few seconds.
> Can it be that 'fossil changes' checks the mtime, while 'fossil commit'
> reads
> all the files?
>

The default setting for Fossil is to use mtime to figure out which files
have changed.  (You can use "fossil setting mtime-changes off" to cause
Fossil to compute a SHA1 checksum over the content of every file in order to
see which files have changed, if you don't trust mtime.)  The use of mtime
allows "fossil changes" and "fossil status" to be quick.

But on a "fossil commit", Fossil computes an MD5 checksum over every file in
the repository, twice.  It computes an MD5 checksum over all files as they
are contained in the repository, and it computes the MD5 checksum over all
files as they exist on disk, and it compares both results to the R-card in
the manifest.  This is a safety check.  Everything has to be right or the
commit will rollback.

This can take a few seconds.  On the other hand, commits are not that
common.  (A few times per day?)  And Fossil goes by the philosophy that
there is no merit in getting the wrong answer quickly.

More information on the cross-checks that Fossil performance can be seen
here:

http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki

These self-checks help to ensure that Fossil never loses or corrupts
content, which is an important property for a VCS.

>
> Does the commit time depend mostly on the checkout size, or the repository
> size?
> If we import all the svn history into our fossil repository, it will mean a
> 200%
> increase in repository size but a 0% increase in checkout size, and we
> doubt
> whether to import it or not.
>
> Thank you,
> Lluís.
>
> ___
> 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

[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 :
> Ramon Ribó  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

[Wolfgang]

Ramon Ribó  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] SSL patch

[James Peverill]

>
> Attached is the same diff from a previous ticket [0]. This fixes some of
> the ssl issues I have on OpenBSD where all certificates are untrusted.
> If anyone still has issues after this patch, I have another one that goes
> through SSL_get_peer_cert_chain and saves the CA and verifies against
> that instead of the client cert this looks like what mutt does when it
> can't verify a client cert.
>
Your patch worked for me!  Thanks I was about to take a look at this 
today since the users have been complaining.

James
___
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

[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 :
> Ramon Ribó  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] Patch file in windows

[Lluís Batlle i Rossell]

On Wed, Oct 06, 2010 at 12:39:15PM +0200, Emil Totev wrote:
> Hello
> This is fossil version [b48f78964e] 2010-09-18 15:51:43 UTC
> on Windows XP SP3
> 
> When I create a patch file using
> fossil diff  > patch.txt
> 
> the resulting file cannot be used for patching. It seems there is an
> extra 0D line separator (0d 0d 0a) for the actual source lines. (---,
> +++, @@ lines are OK).
> 
> The source files have normal Windows line endings, 0d 0a.
I saw the same annoyance in fossil built for cygwin.
I use "fossil diff | tr -d '\r'" to overcome that.
You may also want to set a gdiff-tool, and use 'fossil gdiff', if you have
GNU diffutils available for example. I use that to get diffs in unified format.

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

[fossil-users] Patch file in windows

[Emil Totev]

Hello
This is fossil version [b48f78964e] 2010-09-18 15:51:43 UTC
on Windows XP SP3

When I create a patch file using
fossil diff  > patch.txt

the resulting file cannot be used for patching. It seems there is an
extra 0D line separator (0d 0d 0a) for the actual source lines. (---,
+++, @@ lines are OK).

The source files have normal Windows line endings, 0d 0a.

Is this a bug?

Thanks
Emil
___
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] Using fossil before importing from svn

[Lluís Batlle i Rossell]

On Tue, Sep 28, 2010 at 04:14:01PM -0400, Richard Hipp wrote:
> 2010/9/28 Lluís Batlle i Rossell 
> 
> > Hello,
> >
> > we are going to try to switch from svn into fossil.
> >
> > As we could not find any tool ready to import svn history (even a single
> > branch)
> > into fossil, I think that we are going to keep the svn history in its svn
> > repository, and we will start fossil from a last agreed point in the svn
> > history.
> >
> > Do you think that we will be able, at a later time, to add the 'past'
> > history
> > into our fossil repository, once someone writes a tool to import from svn?
> > Using some kind of deconstruct/reconstruct, with the needed modifications
> > and
> > checksums and hash recalculations.
> >
> 
> That would work.  To make an import tool for pre-history should really be no
> more difficult than making a generic import tool.
> 
> Except for one problem:  When you start your new Fossil repository, you'll
> have an initial version, call is "A".  When you later import the pre-history
> from SVN, version A will not be linked to its parent in SVN.  In other
> words, there will be a gap between the last SVN version and the first Fossil
> version.  But I'm thinking that will be just a minor hiccup.  And it is
> within the realm of possibility that we could enhance Fossil to allow you to
> fix that gap; the Fossil file format would support such a thing - it has
> just not been implemented yet.

I'm just trying that, and I've seen a big problem is the date of the initial
commit, where I want to start putting the old commits from. The initial commit
is quite recent while the svn commits are older.

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

[fossil-users] performance on 'commit'

[Lluís Batlle i Rossell]

Hello,

we have a fossil repository of less than 100 commits, with a checkout of around
300MB, and around 3000 files.

The fossil repository size is about 150MB.

We notice that the 'fossil changes' command is very fast, but 'fossil commit'
lasts for a few seconds.
Can it be that 'fossil changes' checks the mtime, while 'fossil commit' reads
all the files?

Does the commit time depend mostly on the checkout size, or the repository size?
If we import all the svn history into our fossil repository, it will mean a 200%
increase in repository size but a 0% increase in checkout size, and we doubt
whether to import it or not.

Thank you,
Lluís.

___
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

[Wolfgang]

Ramon Ribó  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

[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 :
> Ramon Ribó  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 ?FIE

Re: [fossil-users] CGI, "no such file: cgi"

[fatman]

> Date: Tue, 5 Oct 2010 09:09:14 -0400
> From: Richard Hipp 
> On Tue, Oct 5, 2010 at 7:35 AM,  wrote:
> > My CGI:
> > #!/usr/bin/fossil cgi
> > repository: /home/fatman/https/fossils/reu2.fossil
> 
> Maybe get rid of the "cgi" on the first line.  Just:
> 
> #!/usr/bin/fossil
> repository: /home/fatman/https/fossils/reu2.fossil

That did it. Thanks Richard!

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