Re: [fossil-users] Automatic Ticket-commit tagging

[Stephan Beal]

Steve's summary is as close to accurate as i could have put it. The config
stuff is not stored in permanent artifacts, and can synced but does not
participate in merging and whatnot. Anything UI-independent of potential
historical significance is stored in an artifact.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
On May 23, 2016 23:09, "Ron W"  wrote:

> On Mon, May 23, 2016 at 10:41 AM, Steve Schow  wrote:
>
>> Is it fair to say, tickets, wikis and checkins are stored in artifacts….
>>  while pretty much all configuration stuff including TH1 code, SQL, UI
>> enhancements, etc are probably not artifacted?
>>
>
> I don't know if they are also stored in artifacts. That would be a
> question either for the Fossil source code or Richard. The "fossil config"
> command does allow for pushing/pulling configuration, so there might be
> artifacts, possibly temporary, so that configuration can be pushed/pulled
> using the same mechanism as repository content.
>
>
>> Except for this .fossil-settings folder you mentioned, which I was not
>> aware of…what is in there?
>>
>
> In the Fossil web UI of your repo, go to Admin -> Settings (probably
> http://localhost:8080/setup_settings)
>
> Some of the setting listed on that page are marked with (v). those are the
> version-able settings  Under the edit-able list of settings, there is:
> > Settings marked with (v) are 'versionable' and will be overridden
> > by the contents of files named .fossil-settings/PROPERTY
> > in the check-out root. If such a file is present, the corresponding
> > field above is not editable.
>
> Another way to version the settings is to use "fossil config export" and
> "fossil config import", which save/restore the settings to/from a file that
> could be versioned. However, settings in that file must be explicitly
> imported to be used.
>
>
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Mon, May 23, 2016 at 10:41 AM, Steve Schow  wrote:

> Is it fair to say, tickets, wikis and checkins are stored in artifacts….
>  while pretty much all configuration stuff including TH1 code, SQL, UI
> enhancements, etc are probably not artifacted?
>

I don't know if they are also stored in artifacts. That would be a question
either for the Fossil source code or Richard. The "fossil config" command
does allow for pushing/pulling configuration, so there might be artifacts,
possibly temporary, so that configuration can be pushed/pulled using the
same mechanism as repository content.


> Except for this .fossil-settings folder you mentioned, which I was not
> aware of…what is in there?
>

In the Fossil web UI of your repo, go to Admin -> Settings (probably
http://localhost:8080/setup_settings)

Some of the setting listed on that page are marked with (v). those are the
version-able settings  Under the edit-able list of settings, there is:
> Settings marked with (v) are 'versionable' and will be overridden
> by the contents of files named .fossil-settings/PROPERTY
> in the check-out root. If such a file is present, the corresponding
> field above is not editable.

Another way to version the settings is to use "fossil config export" and
"fossil config import", which save/restore the settings to/from a file that
could be versioned. However, settings in that file must be explicitly
imported to be used.
___
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] Automatic Ticket-commit tagging

[Ron W]

On Sun, May 22, 2016 at 4:42 PM, Steve Schow  wrote:

>
> with regards to this statement…
>
> On May 22, 2016, at 1:40 PM, Ron W  wrote:
>
> > Everything in Fossil is stored in artifacts.
>
> Are ticket reports stored as versioned artifacts?


I should revise that: Everything that isn't configuration is stored in
artifacts. I don't know if any or what portion of configuration is stored
in artifacts.

I do know that so called "version-able settings" rely on files in
.fossil-settings folder in the root of a check-out. These files can be
managed by Fossil the same as any other files. As for how other settings
are stored, even if they are stored in artifacts, Fossil doesn't expose an
interface for accessing nor managing their history.
___
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] Automatic Ticket-commit tagging

[Steve Schow]

Can you please show me where I can find version history of the ticket report 
SQL statement?  I have been copy and pasting this into a text file in order to 
get versioning on it…but if fossil is versioning it already then I don’t need 
to, but I was not able to see any way to do that.



On May 22, 2016, at 6:52 PM, Andy Goth  wrote:

> On 5/22/2016 3:53 PM, Steve Schow wrote:
>> I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
>> versioned artifacts…
> 
> Ticket reports are formatted the same as changes.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] Automatic Ticket-commit tagging

[Andy Goth]

On 5/22/2016 3:53 PM, Steve Schow wrote:
> I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
> versioned artifacts…

Ticket reports are formatted the same as changes.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
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] Automatic Ticket-commit tagging

[Steve Schow]

I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
versioned artifacts…


On May 22, 2016, at 2:50 PM, Andy Goth  wrote:

> On 5/22/2016 3:42 PM, Steve Schow wrote:
>> On May 22, 2016, at 1:40 PM, Ron W  wrote:
>>> Everything in Fossil is stored in artifacts. 
>> 
>> Are ticket reports stored as versioned artifacts?
> 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#tktchng
> 

___
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] Automatic Ticket-commit tagging

[Andy Goth]

On 5/22/2016 3:42 PM, Steve Schow wrote:
> On May 22, 2016, at 1:40 PM, Ron W  wrote:
>> Everything in Fossil is stored in artifacts. 
> 
> Are ticket reports stored as versioned artifacts?

http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#tktchng

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
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] Automatic Ticket-commit tagging

[Steve Schow]

with regards to this statement…

On May 22, 2016, at 1:40 PM, Ron W  wrote:

> Everything in Fossil is stored in artifacts. 

Are ticket reports stored as versioned artifacts?


___
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] Automatic Ticket-commit tagging

[Steve Schow]

ok, but the ticket table does not contain artifacts.  It was not obvious to me 
that tickets are under version control in another place.  It is now.


On May 22, 2016, at 1:40 PM, Ron W  wrote:

> On Sat, May 21, 2016 at 4:36 PM, Steve Schow  wrote:
> Thanks for that information.  I was not aware that ticket changes involved 
> artifacts also.
> 
> Everything in Fossil is stored in artifacts. The DB serves as artifact 
> storage, indexing of artifacts and a convenient cache of data from the 
> artifacts. All the artifacts could be dumped into files, then later, a new DB 
> could be constructed from the artifacts.
>  
>   A few months back when I first started using fossil I batch changed a bunch 
> of tickets using SQL, I changed the value of the subsystem column..  since 
> then I’ve gone in and edited many of the same tickets using the web ui and 
> the subsystem value didn’t seem to revert back to anything, and everything 
> seems fine, but now you have me a little worried that in some cases the 
> artifacts of those tickets will be somehow out of sync with the SQL at some 
> point in the future.
> 
> As long as your repository is not exchanging ticket updates with another, the 
> DB tables should retain all the information.
>  
>  But thanks for the heads up, in the future if I am going to batch update a 
> bunch of tickets I will use the fossil ticket command to do it in some way.
> 
> That would be much safer.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Sat, May 21, 2016 at 4:36 PM, Steve Schow  wrote:

> Thanks for that information.  I was not aware that ticket changes involved
> artifacts also.
>

Everything in Fossil is stored in artifacts. The DB serves as artifact
storage, indexing of artifacts and a convenient cache of data from the
artifacts. All the artifacts could be dumped into files, then later, a new
DB could be constructed from the artifacts.


>   A few months back when I first started using fossil I batch changed a
> bunch of tickets using SQL, I changed the value of the subsystem column..
>  since then I’ve gone in and edited many of the same tickets using the web
> ui and the subsystem value didn’t seem to revert back to anything, and
> everything seems fine, but now you have me a little worried that in some
> cases the artifacts of those tickets will be somehow out of sync with the
> SQL at some point in the future.
>

As long as your repository is not exchanging ticket updates with another,
the DB tables should retain all the information.


>  But thanks for the heads up, in the future if I am going to batch update
> a bunch of tickets I will use the fossil ticket command to do it in some
> way.
>

That would be much safer.
___
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] Automatic Ticket-commit tagging

[Steve Schow]

Thanks for that information.  I was not aware that ticket changes involved 
artifacts also.  I should have known that, but I’m still getting up to speed 
with fossil.  A few months back when I first started using fossil I batch 
changed a bunch of tickets using SQL, I changed the value of the subsystem 
column..  since then I’ve gone in and edited many of the same tickets using the 
web ui and the subsystem value didn’t seem to revert back to anything, and 
everything seems fine, but now you have me a little worried that in some cases 
the artifacts of those tickets will be somehow out of sync with the SQL at some 
point in the future.

 But thanks for the heads up, in the future if I am going to batch update a 
bunch of tickets I will use the fossil ticket command to do it in some way.


On May 21, 2016, at 1:12 AM, Ron W  wrote:

> On Fri, May 20, 2016 at 10:43 AM, Steve Schow  wrote:
> I think perhaps you meant “commit” comment below?  Its the commit comment 
> that needs to be tweaked, in theory, by the TH1…not the ticket itself.   So 
> are you saying that modifying a commit comment requires that an artifact be 
> created with TH1 somehow, if even possible?
> 
> To truly update the commit comment, you need to create a control artifact 
> that "attaches" an updated comment to the commit. This involves two things: 
> Create a string with the required "cards" (see 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) then insert 
> the new artifact into the blob table. I don't know if the TH1 query function 
> will allow doing an insert or update. Have never tried.
>  
> For the ticket table, I noticed in the admin page that there is a SQL insert 
> statement with comments that say we can add our own columns to it for 
> whatever purpose we want.  It already has a status column which could be used 
> to store “working” status, but what I was thinking is I could stash something 
> in a different column that basically indicates its actually THE ONE that is 
> being worked on right now…  I don’t think (?) any artifacts are needed for 
> putting info like that into the ticket table and using TH1 to check out that 
> data from the ticket table…it would not be any new records, but rather an 
> additional column to an existing row in ticket table.
> 
> I think it would be ok to just update the one field in the ticket table. Just 
> be aware that a future update to the same ticket could cause fossil to 
> "forget" that change as there will be no artifact to "remind" it.
> 
> Alternately, both the web UI and the Fossil command line can update fields in 
> a ticket, so a ticket change artifact would automatically be created.
> 
> Which ever way the field gets set, a "SELECT tkt_uuid FROM ticket WHERE 
> working=yes;" should find and return the UUID of the currently "active" 
> ticket.
>  
> However, it makes sense that actually updating the commit comment would be 
> more involved, and plenty of opportunities to get it wrong if there is no API 
> for such a thing in TH1…sounds like  I would need have TH1 issue some SQL 
> that does it…and make sure the SQL is doing things right internally to create 
> this artifact you mentioned holding the updated commit comment.  Yes?
> 
> probabably easier and safer to just put this in the wrapper script I guess.
> 
> Yes. But it might actually be possible to do it with just TH1 hook scripts.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Fri, May 20, 2016 at 10:43 AM, Steve Schow  wrote:

> I think perhaps you meant “commit” comment below?  Its the commit comment
> that needs to be tweaked, in theory, by the TH1…not the ticket itself.   So
> are you saying that modifying a commit comment requires that an artifact be
> created with TH1 somehow, if even possible?
>

To truly update the commit comment, you need to create a control artifact
that "attaches" an updated comment to the commit. This involves two things:
Create a string with the required "cards" (see
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) then insert
the new artifact into the blob table. I don't know if the TH1 query
function will allow doing an insert or update. Have never tried.


> For the ticket table, I noticed in the admin page that there is a SQL
> insert statement with comments that say we can add our own columns to it
> for whatever purpose we want.  It already has a status column which could
> be used to store “working” status, but what I was thinking is I could stash
> something in a different column that basically indicates its actually THE
> ONE that is being worked on right now…  I don’t think (?) any artifacts are
> needed for putting info like that into the ticket table and using TH1 to
> check out that data from the ticket table…it would not be any new records,
> but rather an additional column to an existing row in ticket table.
>

I think it would be ok to just update the one field in the ticket table.
Just be aware that a future update to the same ticket could cause fossil to
"forget" that change as there will be no artifact to "remind" it.

Alternately, both the web UI and the Fossil command line can update fields
in a ticket, so a ticket change artifact would automatically be created.

Which ever way the field gets set, a "SELECT tkt_uuid FROM ticket WHERE
working=yes;" should find and return the UUID of the currently "active"
ticket.


> However, it makes sense that actually updating the commit comment would be
> more involved, and plenty of opportunities to get it wrong if there is no
> API for such a thing in TH1…sounds like  I would need have TH1 issue some
> SQL that does it…and make sure the SQL is doing things right internally to
> create this artifact you mentioned holding the updated commit comment.  Yes?
>
> probabably easier and safer to just put this in the wrapper script I guess.
>

Yes. But it might actually be possible to do it with just TH1 hook scripts.
___
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] Automatic Ticket-commit tagging

[Steve Schow]

I think perhaps you meant “commit” comment below?  Its the commit comment that 
needs to be tweaked, in theory, by the TH1…not the ticket itself.   So are you 
saying that modifying a commit comment requires that an artifact be created 
with TH1 somehow, if even possible?

For the ticket table, I noticed in the admin page that there is a SQL insert 
statement with comments that say we can add our own columns to it for whatever 
purpose we want.  It already has a status column which could be used to store 
“working” status, but what I was thinking is I could stash something in a 
different column that basically indicates its actually THE ONE that is being 
worked on right now…  I don’t think (?) any artifacts are needed for putting 
info like that into the ticket table and using TH1 to check out that data from 
the ticket table…it would not be any new records, but rather an additional 
column to an existing row in ticket table.  

However, it makes sense that actually updating the commit comment would be more 
involved, and plenty of opportunities to get it wrong if there is no API for 
such a thing in TH1…sounds like  I would need have TH1 issue some SQL that does 
it…and make sure the SQL is doing things right internally to create this 
artifact you mentioned holding the updated commit comment.  Yes?

probabably easier and safer to just put this in the wrapper script I guess.


On May 20, 2016, at 8:14 AM, Ron W  wrote:

> On Fri, May 20, 2016 at 2:21 AM, Steve Schow  wrote:
> Hmm, very interesting idea about using the EDITOR feature to run a 
> pre-script…i will have to ponder that…possibly an alternative to using an 
> actual wrapper script….
> 
> Sounds like server side TH1 probably won’t do it.
> 
> throwing a table into the checkout DB would be easy enough to do…can use 
> sqlite directly for that.  Its just a convenient place to put it.  I’d also 
> interact with the repo’s ticket table to look for tickets that are “working” 
> status, etc.  I was also thinking of adding a column to the ticket table in 
> the repo and then putting something there to indicate its the one I’m working 
> on…in which case I was thinking maybe TH1 could somehow pick it up…but it 
> sounds like the commit operation doesn’t get to the TH1 to do some action for 
> adding the ticket uid to its comment?
> 
> Fossil has "post commit" hooks for file commits and ticket updates that run 
> TH1 scripts configured by the Admin/Transfers page in the Fossil web UI.
> 
> While you might be able to change the various tables in the SQL database, 
> creating a "control artifact" to insert in the artifact table will also be 
> required. Other than the artifact table, the DB tables are caches of meta 
> data from the artifacts.
> 
> In theory, a field like "working on" could live only in the ticket table, but 
> could be cleared by other updates to the same ticket.
> 
> However, to insert the ticket ID into a ticket comment will require creating 
> a "control artifact" to contain the modified comment (see 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki)
> 
> Alternately, you can edit the TH1 in the Edit Ticket UI page to support your 
> "working on this ticket right now" field. Then create a Ticket Report that 
> reports the currently "working on" tickets (if more than one ticket is 
> reported, you forgot to make the ticket as not "working on"). Then your 
> wrapper could use "fossil ticket show workReport" to get ID of "working on" 
> ticket and insert that ID in the commit comment.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Fri, May 20, 2016 at 2:21 AM, Steve Schow  wrote:

> Hmm, very interesting idea about using the EDITOR feature to run a
> pre-script…i will have to ponder that…possibly an alternative to using an
> actual wrapper script….
>
> Sounds like server side TH1 probably won’t do it.
>
> throwing a table into the checkout DB would be easy enough to do…can use
> sqlite directly for that.  Its just a convenient place to put it.  I’d also
> interact with the repo’s ticket table to look for tickets that are
> “working” status, etc.  I was also thinking of adding a column to the
> ticket table in the repo and then putting something there to indicate its
> the one I’m working on…in which case I was thinking maybe TH1 could somehow
> pick it up…but it sounds like the commit operation doesn’t get to the TH1
> to do some action for adding the ticket uid to its comment?
>

Fossil has "post commit" hooks for file commits and ticket updates that run
TH1 scripts configured by the Admin/Transfers page in the Fossil web UI.

While you might be able to change the various tables in the SQL database,
creating a "control artifact" to insert in the artifact table will also be
required. Other than the artifact table, the DB tables are caches of meta
data from the artifacts.

In theory, a field like "working on" could live only in the ticket table,
but could be cleared by other updates to the same ticket.

However, to insert the ticket ID into a ticket comment will require
creating a "control artifact" to contain the modified comment (see
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki)

Alternately, you can edit the TH1 in the Edit Ticket UI page to support
your "working on this ticket right now" field. Then create a Ticket Report
that reports the currently "working on" tickets (if more than one ticket is
reported, you forgot to make the ticket as not "working on"). Then your
wrapper could use "fossil ticket show workReport" to get ID of "working on"
ticket and insert that ID in the commit comment.
___
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] Automatic Ticket-commit tagging

[Steve Schow]

Hmm, very interesting idea about using the EDITOR feature to run a pre-script…i 
will have to ponder that…possibly an alternative to using an actual wrapper 
script….

Sounds like server side TH1 probably won’t do it.

throwing a table into the checkout DB would be easy enough to do…can use sqlite 
directly for that.  Its just a convenient place to put it.  I’d also interact 
with the repo’s ticket table to look for tickets that are “working” status, 
etc.  I was also thinking of adding a column to the ticket table in the repo 
and then putting something there to indicate its the one I’m working on…in 
which case I was thinking maybe TH1 could somehow pick it up…but it sounds like 
the commit operation doesn’t get to the TH1 to do some action for adding the 
ticket uid to its comment?


On May 19, 2016, at 11:24 PM, Ron W  wrote:

> On Wed, May 18, 2016 at 2:12 PM, Steve Schow  wrote:
> I’m going to try to make some kind of wrapper script to my commit command 
> that can do this for me, but before I embark I am wondering if anyone has 
> thought of any good ways to do this, perhaps using TH1 in the repo or 
> something….or perhaps using the checkout DB in some way to keep track of what 
> the current ticket is.
> 
> While TH1 has a query function to process SQL expressions in a TH1 script, 
> only the ticket hook script would be able to access the check out DB an donly 
> when triggered by a "fossil ticket" command line command. Even then, I don't 
> know if you'd have access to the check out DB.
> 
> A wrapper script might be able to use "fossil sql" command line commands to 
> store and retrieve info in the check out DB. I've never tried it.
> 
> The SQLite project has a command line client that could be used to store and 
> retrieve info in the check out DB.
> 
> My personal solution to this is to set the Fossil "editor" option to run a 
> script that launches my preferred text editor with the previous commit 
> message preloaded. Then I just edit what needs to be edited, save and quite 
> the editor. Then the script copies the message to the temporary file supplied 
> by Fossil.
> 
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Wed, May 18, 2016 at 2:12 PM, Steve Schow  wrote:
>
> I’m going to try to make some kind of wrapper script to my commit command
> that can do this for me, but before I embark I am wondering if anyone has
> thought of any good ways to do this, perhaps using TH1 in the repo or
> something….or perhaps using the checkout DB in some way to keep track of
> what the current ticket is.
>

While TH1 has a query function to process SQL expressions in a TH1 script,
only the ticket hook script would be able to access the check out DB an
donly when triggered by a "fossil ticket" command line command. Even then,
I don't know if you'd have access to the check out DB.

A wrapper script might be able to use "fossil sql" command line commands to
store and retrieve info in the check out DB. I've never tried it.

The SQLite project has a command line client that could be used to store
and retrieve info in the check out DB.

My personal solution to this is to set the Fossil "editor" option to run a
script that launches my preferred text editor with the previous commit
message preloaded. Then I just edit what needs to be edited, save and quite
the editor. Then the script copies the message to the temporary file
supplied by Fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Automatic Ticket-commit tagging

[Steve Schow]

I am getting tired of having to copy and paste the ticket uid into my commit 
comments in order to automatically link multiple commits to a single ticket.  
The ability to go to a ticket and see the list of checkins associate with it is 
very important to me, but the manual overhead to make it so, is cumbersome.  

I’m going to try to make some kind of wrapper script to my commit command that 
can do this for me, but before I embark I am wondering if anyone has thought of 
any good ways to do this, perhaps using TH1 in the repo or something….or 
perhaps using the checkout DB in some way to keep track of what the current 
ticket is.

Any creative ideas are welcome at this point…




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