Re: [fossil-users] Fossil 2.0: rethinking extras, addremove, and clean

[Andy Goth]

On 5/21/2016 9:03 PM, Joe Mistachkin wrote:
> Andy Goth wrote:
>> The clean command has gotten very complicated, so I further advocate
>> removing the -emptydirs and -dotfiles options and making them always
>> be in effect.  Empty directories requiring preservation should be
>> listed in the empty-dirs setting.  Likewise, dotfiles should be
>> checked in or put in ignore-glob.  I also advocate removing -keep and
>> keep-glob since I really don't know what they do that isn't done
>> better by ignore-glob.
> 
> Unfortunately, most of the complexity is necessary and removing or
> changing the semantics would risk breaking existing repositories,
> including some of the ones I use on a daily basis.

Yup, hence the "Fossil 2.0" in the subject line.  But I'm very
interested to know how you use the features I'm struggling to myself
find a use fur.

-- 
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] Fossil 2.0: rethinking extras, addremove, and clean

[Joe Mistachkin]

Andy Goth wrote:
>
> My recommendation is to keep the promise made by the current addremove
> documentation.  That is to say, make extras and adds be equal.  This
> means changing the extras command to also ignore files matched by
> clean-glob: extras = adds = tree - managed - ignore-glob.
> 

I do not recall the exact rationale behind the existing semantics;
however, I'm pretty sure there was a length discussion (or two) on the
mailing list at some point.

> 
> The clean command has gotten very complicated, so I further advocate
> removing the -emptydirs and -dotfiles options and making them always be
> in effect.  Empty directories requiring preservation should be listed in
> the empty-dirs setting.  Likewise, dotfiles should be checked in or put
> in ignore-glob.  I also advocate removing -keep and keep-glob since I
> really don't know what they do that isn't done better by ignore-glob.
> 

Unfortunately, most of the complexity is necessary and removing or changing
the semantics would risk breaking existing repositories, including some of
the ones I use on a daily basis.

--
Joe Mistachkin

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

[fossil-users] Fossil 2.0: rethinking extras, addremove, and clean

[Andy Goth]

I've always been bothered by the interaction between extras, addremove,
and clean.  Let's explore the current situation, its problems, how to
deal with them in current Fossil, and how Fossil 2.0 could do better.

I'll start by precisely explaining the current behavior as I understand
it.  First, I need to define sets.  I'll be using "+" and "-" operators
to denote inclusion (files in either lhs or rhs, a.k.a. union) and
exclusion (files in lhs but not rhs), respectively.

tree= files in source tree
checkout= files in whichever check-in is currently checked out
added   = files added pending commit
removed = files removed pending commit
admin   = .fslckout (or _FOSSIL_) and the repository itself
ignore-glob = files matching the ignore-glob setting
keep-glob   = files matching the keep-glob setting
clean-glob  = files matching the clean-glob setting

Here are some derived sets:

managed = files known to Fossil
missing = files missing from source tree
extras  = files to be displayed by the extras command
adds= files to be added by the addremove command
removes = files to be removed by the addremove command
cleans  = files to be cleaned by the clean command

And here is how they are found, as far as I know:

managed = checkout + added + removed + admin
missing = checkout - tree - removed
extras  = tree - managed - ignore-glob
adds= tree - managed - ignore-glob - clean-glob
removes = missing
cleans  = tree - managed - ignore-glob - keep-glob

The fact that adds excludes clean-glob is not immediately obvious from
the addremove documentation.  In fact, it starts by categorically
stating that it adds "all the files displayed using the 'extras'
command".  clean-glob is only an afterthought split across two sections,
and its effect on addremove is not mentioned in the settings help.  I
didn't know this until just a few hours ago.

We can make the addremove and settings documentation be clearer.
However, what would we say?  In effect, addremove adds all files which
clean would ask about if passed the -prompt option.  While accurate,
this is clumsy, non-obvious, and hard to conceptualize.

My recommendation is to keep the promise made by the current addremove
documentation.  That is to say, make extras and adds be equal.  This
means changing the extras command to also ignore files matched by
clean-glob: extras = adds = tree - managed - ignore-glob.

To me, extras is the list of files that are candidates for introduction
into configuration management.  I don't look to extras to give me a list
of files that clean would delete without asking or permitting undo.  I
look to extras to see what I should add versus what's an ad-hoc backup I
may want to delete by hand.

Here's that last paragraph again, written using the above notation:

extras = tree - managed - ignore-glob - clean-glob
adds   = tree - managed - ignore-glob - clean-glob
cleans = tree - managed - ignore-glob - keep-glob

To get something akin to my desired behavior, I've been setting
ignore-glob (instead of clean-glob) to be my generated files, then using
"clean -x" which disregards ignore-glob.  The drawback is undesirable
side effects of -x: -disable-undo and disregarding keep-glob.

The clean command has gotten very complicated, so I further advocate
removing the -emptydirs and -dotfiles options and making them always be
in effect.  Empty directories requiring preservation should be listed in
the empty-dirs setting.  Likewise, dotfiles should be checked in or put
in ignore-glob.  I also advocate removing -keep and keep-glob since I
really don't know what they do that isn't done better by ignore-glob.

There is another anomaly I noticed in my research.  clean won't delete a
file that was marked for removal pending commit but still present in the
tree.  Maybe it should since it's now an extra, unmanaged file.  But the
way to accomplish this isn't by taking removed out of the definition of
managed (above), since that would be putting such files into adds, and
it seems surprising for addremove to counteract the effect of forget.
Instead, if we want this change at all, clean would have to specially go
out of its way to delete forgotten files still lurking in the tree.

-- 
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] Branch and tag metadata

[Andy Goth]

On 5/21/2016 6:27 PM, John P. Rouillard wrote:
> In message <3d27b874-c4db-f4e9-956f-7bbfd651b...@gmail.com>,
> Andy Goth writes:
>> How about tags?  Put the description in the check-in manifest of the
>> first usage of the tag, I suppose.
> 
> That's my thought. IIUC a property with no value is the definition of
> a tag. Making the value of a tag be its description would stop it from
> being interpreted as a tag.

What we're really talking about here is symbolic tags, i.e. names used
to identify check-ins.  A symbolic tag is a tag whose name starts with
the "sym-" prefix.  Whether or not a tag is propagating (i.e. is a
branch) or has a value (i.e. is also a property) is immaterial.

> So you would need to use a separate property to hold the description.
> The description for the tag "tagname" would be held in the
> "tagname-description" property for example.

Actually I think the tag value might be a good place for it after all.
For example: "T sym-tagname * description\sgoes\shere"

I did a quick check and found that symbolic tags still succeed in naming
check-ins despite being given values.  The timeline refers to them as
tags having "notes".  This appears to be unrelated to tech notes.

>> What if a tag is used multiple times?  I'm guessing use the newest
>> which contains the tag-description property.
> 
> Use the tag-description on the revision identified with the
> tag. E.G.
> 
>   fossil co myrelease
> 
> may have two candidates:
> 
>   "myrelease", revision deadbeef done a month ago with a myrelease-description
>   "myrelease", revision beefdead done a day ago with no myrelease-description
> 
> if you look at details for the myrelease on beefdead, you
> will see no description. Similarly you will see a
> description if you look at the "myrelease" associated with
> deadbeef.
> 
> It would be a mistake to associate the deadbeef description
> with the myrelease tag on beefdead.

I'm not so sure.  I wasn't thinking this description capability would be
used for describing individual check-ins (or releases) since that's what
the check-in comment is for.  Instead I think it's for describing a tag,
even a tag used multiple times.  For example, what does "myrelease"
mean?  Maybe it's used to signify any version that is released to an
in-house group, as opposed to a version that's put in a box and sold at
Wal-Mart.  So somewhere in the repository there should be a control
artifact or manifest saying:

T sym-myrelease * released\sto\san\sin-house\sgroup

But I don't think it's worthwhile to repeat that description every time
something gets labeled as a myrelease.

Same goes for branches, if there are branch names that get periodically
recycled and have the same logical purpose each time.

>> Does anyone use the "branch new" command?  It's a relic from the old
>> way of doing branches.  I'm not opposed to this suggestion, just
>> asking.
> 
> I am working on a gitflow technique and this is the command I am using
> to create the feature branch and have the user move to that branch so
> they can't accidently check back into the development branch line.
> Hence my reason for raising it.

Got it, thanks.

> Maybe a:
> 
>--tag-description tagname=description
> 
> where "tagname" must exist already on the revision, or be
> getting created as part of the commit. That way you can
> branch and tag at the same time using --description for the
> branch description and --tag-description for the tag(s).

Another way to handle this is to make the -description option apply to
the -tag or -branch option to its immediate left.  However, I'm not sure
if the Fossil option parser system is up to this task though.

f commit\
-tag release -description "delivered to customer"\
-tag release-1.23
-branch stable -description "accepts only QA-approved changes"\
-comment "Release 1.23"

The resulting check-in would be tagged release and release-1.23 and
would begin the stable branch.  The release tag and stable branch would
be given descriptions.  As I suggested above, these descriptions only
have to be done once, so it won't be necessary in the future to describe
release or stable unless their descriptions are to be changed.

I just had a thought.  How does one describe tags and branches that
aren't yet in use anywhere?  This might be helpful when starting a new
project that is intended to comply with some standardized naming.
Perhaps add a control artifact (not a manifest) that claims to put the
tag on itself, i.e. by using * as the artifact ID.  Then the tag and
description will be mentioned somewhere in the repository without
actually being applied to any manifests.

> This brings up another question, should tagname-description be deleted
> if tagname is deleted from a revision? Similarly for a branch tag.

Storing them together in a single tag like I suggest would give you this
seemingly desirable behavior for free.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature

Re: [fossil-users] Branch and tag metadata

[John P. Rouillard]

Hi Andy:

In message <3d27b874-c4db-f4e9-956f-7bbfd651b...@gmail.com>,
Andy Goth writes:
>On 5/21/2016 4:53 PM, John P. Rouillard wrote:
>> In message ,
>> "Tony Papadimitriou" writes:
>>> I've had the same wish for a long long time.  I would
>>> like the FOSSIL BRANCH list to show except for the
>>> branch name some kind of description. [...]
>>>
>>> So, I think the simplest way to add this functionality
>>> *without* causing backward compatibilities or file
>>> format changes is to display the first commit comment
>>> for that particular branch as a description in the
>>> BRANCH list command.  [...]
>>
>> Since tags are really just properties, what about a
>> convention for adding a branch-description property along
>> side the branch=BRANCHNAME property.
>> 
>> Thus to add a description, you can run:
>> 
>>   fossil add tag branch-description CHECKIN \
>>   "This branch implements the flooze feature, \
>>[...] see BRANCH:flooble wiki [...]"
>> 
>> where checkin is the revision with the branch= property set.
>>
>That's a good thought.  The backward-incompatible part of
>my initial suggestion was due to not knowing where else to
>store the branch or tag description.  I also suggested
>using the wiki but with drawbacks.  The location you
>suggest makes sense, plus would leverage the existing
>artifact amendment infrastructure.
>
>It's also related to Tony's suggestion in that you both
>propose storing the description in the first check-in of
>the branch, but you go a step farther by using a property
>rather than recycling the comment.
>
>How about tags?  Put the description in the check-in
>manifest of the first usage of the tag, I suppose.

That's my thought. IIUC a property with no value is the
definition of a tag. Making the value of a tag be its
description would stop it from being interpreted as a tag.

So you would need to use a separate property to hold the
description.  The description for the tag "tagname" would be
held in the "tagname-description" property for example.

Richard, is there any documentation on the meanings of the
various properties/tags? This is what I think is true:

  prop name value comment
  anything  null  is a tag

  sym-anything  null  is a propagating tag?? 
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki
indicates that sym is a symbol but without
saying what a symbol is. Also propagating/non-propagating
and removal/closing  is controlled by the value of the
field in the T record. One of: +, -, * 

  branchbranch-name   define a branch with name branch-name
  closednone  indicates the branch is closed
  bgcolor   color assigns color to the displayed branch
  cancels a tag (what does this??)

  user  a userall three of these amend the
  comment   text  checkin manifest values 
  date  a date

>What if a tag is used multiple times?  I'm guessing use the
>newest which contains the tag-description property.

Use the tag-description on the revision identified with the
tag. E.G.

  fossil co myrelease

may have two candidates:

  "myrelease", revision deadbeef done a month ago with a myrelease-description
  "myrelease", revision beefdead done a day ago with no myrelease-description

if you look at details for the myrelease on beefdead, you
will see no description. Similarly you will see a
description if you look at the "myrelease" associated with
deadbeef.

It would be a mistake to associate the deadbeef description
with the myrelease tag on beefdead.

>Same goes for branches.  Though hopefully there won't be
>more than one instance per tag or branch.

As long as the revision where the branch is created or tag
is assigned is the same revision where the description is
attached, I don't think there is an issue.

>> As an enhancement to the branch command
>> 
>>fossil branch new BRANCH-NAME BASIS ?OPTIONS?
>> 
>> add an option "--description" that sets the value for the
>> branch-description value at branch time.
>
>Does anyone use the "branch new" command?  It's a relic
>from the old way of doing branches.  I'm not opposed to
>this suggestion, just asking.

I am working on a gitflow technique and this is the command
I am using to create the feature branch and have the user
move to that branch so they can't accidently check back into
the development branch line. Hence my reason for raising it.

>Though I would go a step further and add the -description
>option (maybe renamed -branch-description) to commit so a
>description can be set at the same time as creating the
>branch by that method, much more common these days.

Fair enough.

>I suggest wrapping creating/modifying/deleting branch
>description into new subcommands of branch.  Possibly:
>
>fossil branch describe BRANCH-NAME ?DESCRIPTION?
>
>If DESCRIPTION is omitted, 

[fossil-users] keep-glob

[Andy Goth]

What is keep-glob good for?  Does anyone use it in their projects?  Or
the -keep option to clean?

Only the clean command reads keep-glob, but the thing it uses it for
could also be done with ignore-glob.

Of course ignore-glob also effects extras and addremove.  However, I
can't think of any realistic motivating cases where a file would need to
be spared from clean but also be subject to addition via addremove.

(By the way, I frequently use open -keep and checkout -keep, but despite
the name they're unrelated to clean -keep.)

-- 
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] Branch and tag metadata

[Andy Goth]

On 5/21/2016 4:53 PM, John P. Rouillard wrote:
> In message ,
> "Tony Papadimitriou" writes:
>> I've had the same wish for a long long time.  I would like the FOSSIL BRANCH 
>> list to show except for the branch name some kind of description.
>> Like you mentioned, making the branch name itself long enough would be one 
>> way to tackle this but it is counter-productive as you would need to type 
>> the whole thing each time you need to access that branch.
>>
>> So, I think the simplest way to add this functionality *without* causing 
>> backward compatibilities or file format changes is to display the first 
>> commit comment for that particular branch as a description in the BRANCH 
>> list command.
>>
>> Although it may not always be the most accurate description for branches 
>> already created, I think in most cases the first branch commit comment 
>> represents a pretty good description about what the branch is about, or why 
>> it had to be created.
> 
> Since tags are really just properties, what about a convention for
> adding a branch-description property along sinde the branch=BRANCHNAME
> property.
> 
> Thus to add a description, you can run:
> 
>   fossil add tag branch-description CHECKIN "This branch implements the 
> flooze feature, see the BRANCH:flooble wiki page for details."
> 
> where checkin is the revision with the branch= property set.

That's a good thought.  The backward-incompatible part of my initial
suggestion was due to not knowing where else to store the branch or tag
description.  I also suggested using the wiki but with drawbacks.  The
location you suggest makes sense, plus would leverage the existing
artifact amendment infrastructure.

It's also related to Tony's suggestion in that you both propose storing
the description in the first check-in of the branch, but you go a step
farther by using a property rather than recycling the comment.

How about tags?  Put the description in the check-in manifest of the
first usage of the tag, I suppose.

What if a tag is used multiple times?  I'm guessing use the newest which
contains the tag-description property.  Same goes for branches.  Though
hopefully there won't be more than one instance per tag or branch.

> As an enhancement to the branch command
> 
>fossil branch new BRANCH-NAME BASIS ?OPTIONS?
> 
> add an option "--description" that sets the value for the
> branch-description value at branch time.

Does anyone use the "branch new" command?  It's a relic from the old way
of doing branches.  I'm not opposed to this suggestion, just asking.

Though I would go a step further and add the -description option (maybe
renamed -branch-description) to commit so a description can be set at
the same time as creating the branch by that method, much more common
these days.

I suggest wrapping creating/modifying/deleting branch description into
new subcommands of branch.  Possibly:

fossil branch describe BRANCH-NAME ?DESCRIPTION?

If DESCRIPTION is omitted, print the description.  Otherwise set it,
though if DESCRIPTION is empty string, cancel the description property.

Do the same for tags:

fossil tag describe TAG-NAME ?DESCRIPTION?

But I don't think a -tag-description option to commit would work well
since there's no sure way to relate which -tag-description option goes
with which -tag option, of which there can be multiple.  It's a
non-issue for branches since only one -branch can be specified.  So
yeah, don't rename -description to -branch-description; it's unambiguous
as it is.

On top of all this, I'd still like for the branch and tag list pages to
link to wiki pages with the same name as the branch or tag.  This
provides a place to discuss the branch or tag, to link to tickets and
email archives, and to have attachments.

-- 
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] Branch and tag metadata

[John P. Rouillard]

Hi all:

In message ,
"Tony Papadimitriou" writes:
>I've had the same wish for a long long time.  I would like the FOSSIL BRANCH 
>list to show except for the branch name some kind of description.
>Like you mentioned, making the branch name itself long enough would be one 
>way to tackle this but it is counter-productive as you would need to type 
>the whole thing each time you need to access that branch.
>
>So, I think the simplest way to add this functionality *without* causing 
>backward compatibilities or file format changes is to display the first 
>commit comment for that particular branch as a description in the BRANCH 
>list command.
>
>Although it may not always be the most accurate description for branches 
>already created, I think in most cases the first branch commit comment 
>represents a pretty good description about what the branch is about, or why 
>it had to be created.

Since tags are really just properties, what about a convention for
adding a branch-description property along sinde the branch=BRANCHNAME
property.

Thus to add a description, you can run:

  fossil add tag branch-description CHECKIN "This branch implements the flooze 
feature, see the BRANCH:flooble wiki page for details."

where checkin is the revision with the branch= property set.

As an enhancement to the branch command

   fossil branch new BRANCH-NAME BASIS ?OPTIONS?

add an option "--description" that sets the value for the
branch-description value at branch time.

According to

   http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

this should work to associate metadata with a checkin artifact.

Comments?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Branch and tag metadata

[Tony Papadimitriou]

I've had the same wish for a long long time.  I would like the FOSSIL BRANCH 
list to show except for the branch name some kind of description.
Like you mentioned, making the branch name itself long enough would be one 
way to tackle this but it is counter-productive as you would need to type 
the whole thing each time you need to access that branch.


So, I think the simplest way to add this functionality *without* causing 
backward compatibilities or file format changes is to display the first 
commit comment for that particular branch as a description in the BRANCH 
list command.


Although it may not always be the most accurate description for branches 
already created, I think in most cases the first branch commit comment 
represents a pretty good description about what the branch is about, or why 
it had to be created.


My €0.02

Another wish is for the BRANCH list to show if a branch is private.  This 
would be very helpful to me (at least).


Add another €0.01

-Original Message- 
From: Andy Goth

Sent: Saturday, May 21, 2016 5:39 AM
To: Fossil Users Mailing List
Subject: [fossil-users] Branch and tag metadata

I'm thinking I might want the ability to describe branches and tags
separate from the check-in comments.
...
But creating a space to provide a short description (akin to a check-in 
comment) of branches and tags could require a new type of control artifact.


Any thoughts?

___
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