Re: [fossil-users] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

[Eric Rubin-Smith]

Ron W wrote: 

> This enhancement to Fossil will certainly make integration with other 
> tools easier, not just Slack 

I was thinking of an example: git.  Right now there's a bulk import 
from git, and a bulk export to git.  The present feature might be used 
along with git's hooks features to permit an automated, bidirectional 
incremental sync between git and fossil repositories, which might help 
ease some users' transitions from git to fossil (possibly encouraging
more fossil uptake).  

-- 
Eric A. Rubin-Smith

___
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] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

[Joe Mistachkin]

I think these changes should work:

https://www.fossil-scm.org/index.html/info/acb61e5ee9

Please let me know if there are any issues.  Unless there are serious
objections,
I would really like to have these changes included in the upcoming 1.30
release.

--
Joe Mistachkin

___
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] "how to use git to lose data"

[Scott Robison]

On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams  wrote:

> > git branch -D name
>
> Eh, filesystems let you delete files.  Unlike most filesystems, git lets
> you restore your deleted branches (yes, provided you don't gc the repo).
>

Then just use a file system and various command line tools! But seriously,
it's a philosophical difference between those who want to be able to
rewrite their history to what they should have done and those who want to
keep the history around to see what they did. It's not perfect, and
certainly there are arguments for both approaches, but git seems fragile to
some people while fossil seems inflexible to others.

-- 
Scott Robison
___
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] "how to use git to lose data"

[Nico Williams]

On Sat, Sep 06, 2014 at 10:22:13AM +0200, Stephan Beal wrote:
> On Fri, Sep 5, 2014 at 10:03 PM, Nico Williams 
> wrote:
> > To me the "designed to forget" comments seem like a
> > stretch.
> >
> 
> git branch -D name

Eh, filesystems let you delete files.  Unlike most filesystems, git lets
you restore your deleted branches (yes, provided you don't gc the repo).
___
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] Tags in comment document

[B Harder]

On Sep 6, 2014 11:11 AM, "Stephan Beal"  wrote:
>
> On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall 
wrote:
>>
>> whether it should really say branch rather than tags. Is this a bug, or
is it really meant to be branch rather than tags?
>
>
> It's probably just an oversight. IIRC, the --tag option to commit was
added relative recently (within the past year), and in my experience most
people provide the message on the command line, so they never see that. i
honestly can't remember the last time i let an scm start up an editor to
type in my commit message (several years, at the very least).

I do occasionally, and the rational came from an article I read on git
commits.  Roughly: put the briefest 80-col description on one line, next
para expands on that as necessary, and longer description follows (if
necessary). Our current default commit descriptions don't do anything
useful with this type of formatting, but it's easy to imagine spinning up
tooling that would. Facilities that used this (or similar) style of
formatting would encourage more people to adopt the style, which would not
be a bad thing.

> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> 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] Tags in comment document

[Will Parsons]

Stephan Beal wrote:
>
> It's probably just an oversight. IIRC, the --tag option to commit was added
> relative recently (within the past year), and in my experience most people
> provide the message on the command line, so they never see that. i honestly
> can't remember the last time i let an scm start up an editor to type in my
> commit message (several years, at the very least).

I'm really surprised by that.  I've always used an editor to type in
comments, not only in Fossil, but in Bazaar and Mercurial also (and
RCS, though RCS doesn't provide for using an external editor).  Why
wouldn't you?  It's so much easier to compose the message and correct
typing mistakes if one is doing it in an editor rather than on the
command line.  The only situation where I would pass the comment on
the command line is if it part of script of some sort.

-- 
Will

___
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] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

[Joe Mistachkin]

Great.  I'll start making the necessary tweaks to expose the UUID(s).  Also,
I think
Ron W has a point about the variable naming, I think the list of UUIDs
should be named
"uuids".

--
Joe Mistachkin

___
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 for web site maintenance [was "how to use git to lose data"]

[Ron W]

On Sat, Sep 6, 2014 at 12:47 PM, Miles Fidelman 
wrote:

> Thanks Richard. I do really like that feature - though if the
> branching/merging features worked for documentation that would be even
> better, and even better if the embedded wiki supported branching/merging
> within the embedded wiki!  That would be a thing of beauty.  Unfortunately,
> I'm not enough of a code monkey to do that myself.
>

The "Embedded Documents" are handled like other project files in your
workspace. You edit them and commit them via the CLI, and can do branching
and merging the same as any other files in your work space. They do get
some special treatment in Fossil's web interface. See
http://fossil-scm.org/index.html/doc/tip/www/embeddeddoc.wiki

This is different from "Fossil Wiki" pages.
___
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] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

[Ron W]

On Sat, Sep 6, 2014 at 11:21 AM, Eric Rubin-Smith  wrote:

> This post is a testament to Fossil's design and the ease of reading its
> implementation.  I've also added a Fossil patch
>
[...]

> It requires a little hacking of the Fossil source to expose some data to
> the TH1 "Transfer" hooks.  But basically we can just use the
> Admin->Transfers->Push and Admin->Transfers->Ticket TH1 hooks to get what
> we want.  Slack has a nice little HTTP API for messaging, so once the data
> is in TH1 you just massage it into an appropriate HTTP call.
>
[...]

> The issue with this is that we need to set the $uuid variable from the C
> implementation prior to invoking the script.  The issue is slightly
> trickier for commit notifications (the Admin->Transfers->Push case), since
> we can receive multiple artifacts in one Push operation.  I opted to
> provide a list of UUIDs to a single invocation of the script, rather than
> one UUID for each of multiple invocations.  This allows the script more
> flexibility.  (Right now the variable is called $uuid rather than e.g.
> $uuidList, which is something I can fix if the devs like the general
> approach.)
>

I am surprised this was not already available.

I would use either $uuids or $uuidList to make it clear there could be more
than 1 uuid.

This enhancement to Fossil will certainly make integration with other tools
easier, not just Slack
___
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] Tags in comment document

[Philip Bennefall]

Hi Stephan,

Personally I use what is called a screen reader, which enables blind and 
visually impaired users to use computers. When writing in a text editor 
such as notepad it is easier and more convenient to edit text, as 
opposed to doing it straight on the command line if it spans over more 
than a single line. Hence my preference for the editor approach; 
especially given the fact that I also get the list of changes presented 
to me immediately. It would be great if it would also show all of the tags.


Kind regards,

Philip Bennefall
On 9/6/2014 8:11 PM, Stephan Beal wrote:
On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall > wrote:


whether it should really say branch rather than tags. Is this a
bug, or is it really meant to be branch rather than tags?


It's probably just an oversight. IIRC, the --tag option to commit was 
added relative recently (within the past year), and in my experience 
most people provide the message on the command line, so they never see 
that. i honestly can't remember the last time i let an scm start up an 
editor to type in my commit message (several years, at the very least).


--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct 
of those who insist on a perfect world, freedom will have to do." -- 
Bigby Wolf


___
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 for web site maintenance [was "how to use git to lose data"]

[Scott Robison]

On Sat, Sep 6, 2014 at 9:52 AM, Miles Fidelman 
wrote:

> Scott Robison wrote:
>
>> ... One of my newest uses for fossil is the one case in which I'm using
>> it distributed (even though all by myself): My blog (such as it is). It is
>> not a unique idea at all, but I finally tired of heavy weight blog
>> platforms and decided I wanted to just keep track of things in text files.
>> I've started using the pelican static site generator to keep all my site's
>> source files (restructured text files in a content tree & config files &
>> etc) as well as the generated files (public tree). I only maintain the site
>> on my home computer (including generating the public stuff), but then I
>> commit & sync it to the remote server and update the live site, making the
>> generated file tree available (and giving me a "live" backup of all the
>> files).
>>
>>  A little late getting back to this, but...
>
> Scott, can you say a little more about your tool chain, end to end from
> editing to online?  (I've been thinking about doing something similar, but
> for maintaining some project documentation and works in progress).


It's been a while since I started, so there may be some amounts of "hand
waving" over things I don't remember exactly, but:

1. I installed the pelican static site generator along with its
prerequisites: http://blog.getpelican.com/

2. I had been using a private Wordpress installation, so I exported that
database somehow and used some utility to convert it to restructured text
files.

3. I use Notepad++ on Windows 7 for my text editing, and a command prompt
for organizing files (moving or deleting some older blog posts that I
didn't want in the exported blog for whatever reason).

4. I wrote a few simple scripts in PHP to provide a very basic chisel-esque
management portal on my website; they are used to create repos, change
passwords, and provide a front end to all my repositories. Using that I
created my initial empty repo.

5. I cloned/opened the repo to my Windows 7 machine and added all the
source and generated public files.

6. I synced that back to my server and opened the repo in the web
directory, organized so that my public directory is the only one published.

7. Because I was porting an older blog to this new system, I had a fair
number of media files (mostly images, some audio, a sprinkling of others)
that were not in the Wordpress database, only in the old file system. So as
I cleaned up each of the approximately 100 posts on my Win7 box, I would
move media from the old location of my blog on the server to the open
workspace, add them and commit them server side.

8. Update on Win7 to get the changes.

9. Regenerate the blog, addremove, commit, sync to the server.

10. Update the server side and check out my work, making any needed tweaks
to ensure everything was presented essentially as I wanted it.

11. Repeat steps 7 through 10 for each of the posts.

It's not a very impressive or sophisticated workflow IMO, but it did what I
wanted quite nicely. While the blog itself is also not terribly impressive
and not frequently updated (though I keep meaning to change that!) you can
see it's current state at www.casaderobison.com. I've cleaned up all the
posts and made sure all the media is available. I still have work to do
cleaning up the category/tag system and tweaking the theme to my liking.

I hope that answers the questions and wasn't *too* tedious. :)

-- 
Scott Robison
___
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] Tags in comment document

[Stephan Beal]

On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall 
wrote:

> whether it should really say branch rather than tags. Is this a bug, or is
> it really meant to be branch rather than tags?
>

It's probably just an oversight. IIRC, the --tag option to commit was added
relative recently (within the past year), and in my experience most people
provide the message on the command line, so they never see that. i honestly
can't remember the last time i let an scm start up an editor to type in my
commit message (several years, at the very least).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 for web site maintenance [was "how to use git to lose data"]

[Miles Fidelman]

Richard Hipp wrote:


On Sat, Sep 6, 2014 at 11:52 AM, Miles Fidelman 
mailto:mfidel...@meetinghouse.net>> wrote:


Scott Robison wrote:

 One of my newest uses for fossil is ... My blog


Scott, can you say a little more about your tool chain,...


I'll let Scott answer the specific question.  But I just want to 
remind Miles of the "Embedded Documentation" feature of Fossil 
(http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki) and 
that the main Fossil website including all of the on-line 
documentation is really just a running instance of Fossil serving the 
Fossil self-hosting repository.  (All of the main website, except the 
Download page, that is.)So if you are a committer, updating the Fossil 
documentation is as simple as editing the document files on your local 
machine and then typing "fossil commit". No logging into servers or 
taking other actions are necessary to publish - publication is automatic.

--


Thanks Richard. I do really like that feature - though if the 
branching/merging features worked for documentation that would be even 
better, and even better if the embedded wiki supported branching/merging 
within the embedded wiki!  That would be a thing of beauty.  
Unfortunately, I'm not enough of a code monkey to do that myself.


Meanwhile, for the documentation I'm working on, I'm looking more at 
stuff that comes out in DocBook format, with indexing and such.  So I'm 
thinking more of treating individual pages as something to be edited and 
version controlled, with auto assembly into the current live version - 
hence my interest in Scott's tool chain.


Thanks,

Miles
___
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 for web site maintenance [was "how to use git to lose data"]

[Richard Hipp]

On Sat, Sep 6, 2014 at 11:52 AM, Miles Fidelman 
wrote:

> Scott Robison wrote:
>
>>  One of my newest uses for fossil is ... My blog
>>
>
> Scott, can you say a little more about your tool chain,...
>

I'll let Scott answer the specific question.  But I just want to remind
Miles of the "Embedded Documentation" feature of Fossil (
http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki) and that the
main Fossil website including all of the on-line documentation is really
just a running instance of Fossil serving the Fossil self-hosting
repository.  (All of the main website, except the Download page, that is.)

Because the Fossil website is served from a live Fossil repository, any of
the dozens of Fossil contributors can make a change to documentation by
editing some files, then doing a "fossil commit" of the changes.  The
changes get pushed automatically to the main Fossil repo at
http://www.fossil-scm.org/ and are immediately visible to readers.  And
within minutes a cron-job will further push those changes out the the
(geographically distributed) backup Fossil websites at
http://www2.fossil-scm.org/ and http://www3.fossil-scm.org/ where the
changes are automatically displayed there as well.

So if you are a committer, updating the Fossil documentation is as simple
as editing the document files on your local machine and then typing "fossil
commit". No logging into servers or taking other actions are necessary to
publish - publication is automatic.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil for web site maintenance [was "how to use git to lose data"]

[Miles Fidelman]

Scott Robison wrote:
On Tue, Sep 2, 2014 at 2:44 AM, Gour > wrote:


9) Source control system is not only for keeping the code - here it's
used for very general writings (even non-computer-related). (too)
specific = selfish, universal = broad-minded.


Interesting you should write this. One of my newest uses for fossil is 
the one case in which I'm using it distributed (even though all by 
myself): My blog (such as it is). It is not a unique idea at all, but 
I finally tired of heavy weight blog platforms and decided I wanted to 
just keep track of things in text files. I've started using the 
pelican static site generator to keep all my site's source files 
(restructured text files in a content tree & config files & etc) as 
well as the generated files (public tree). I only maintain the site on 
my home computer (including generating the public stuff), but then I 
commit & sync it to the remote server and update the live site, making 
the generated file tree available (and giving me a "live" backup of 
all the files).



A little late getting back to this, but...

Scott, can you say a little more about your tool chain, end to end from 
editing to online?  (I've been thinking about doing something similar, 
but for maintaining some project documentation and works in progress).


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

[fossil-users] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

[Eric Rubin-Smith]

This post is a testament to Fossil's design and the ease of reading its
implementation.  I've also added a Fossil patch at the bottom.  I humbly
hope the devs will incorporate it into the product, or tell me what is
wrong with it so I can perhaps fix it.  Otherwise, I hope the community
finds it useful or at least interesting.

Someone recommended to our team that we start using Slack (http://slack.com)
for intra-team instant messaging, file exchange, etc.  One of its nice
features is that it has automated hooks from Jira (a ticket system, as you
probably know) and Bitbucket (a Git hosting blah blah whatever, as you
probably know).  You change a ticket status or make a commit, you
immediately get a little IM to your team with a hyperlink to what
happened.  Fancy.  Slack is pretty cool in general, so it seems likely that
my team will keep using it.

I'm pushing for Fossil within my team.  The size of the Git ecosystem is a
point in Git's favor and a ding on Fossil.  Wishing to erode from this
vis-a-vis the Git->Slack integration, I asked myself, "How fast can we hook
fossil up to this bad boy?"

Answer: really fast.

It requires a little hacking of the Fossil source to expose some data to
the TH1 "Transfer" hooks.  But basically we can just use the
Admin->Transfers->Push and Admin->Transfers->Ticket TH1 hooks to get what
we want.  Slack has a nice little HTTP API for messaging, so once the data
is in TH1 you just massage it into an appropriate HTTP call.

So the idea can be easily extended to any HTTP service that accepts active
notifications.

Perhaps there is a better way to accomplish this.  But a bunch of googling
& mailing list scraping yielded only Andreas's 'fx' package, which seemed
slightly larger than what I was looking for.  Let me know if I missed
something.

Here's my first hack at the TH1 script for publishing ticket info to the
remote HTTP API:

===
tclInvoke package require http
tclInvoke package require tls
tclInvoke http::register https 443 tls::socket
set url "https://slack.com/api/chat.postMessage";

query {SELECT title, assignedTo, status, resolution, releaseGate, type,
priority, severity FROM ticket WHERE tkt_uuid=$uuid} {
  set msgText "*Title*:
/tktview?name=$uuid|$title>\n\n*Type*:
$type\n*Priority*: $priority\n*Assigned To*: $assignedTo\n*Status*: $status"

  if {$status ne "Open"} {
set msgText "$msgText\n*Resolution*: $resolution"
  }
  if {$releaseGate ne ""} {
set msgText "$msgText\n*Release Gate*: $releaseGate"
  }

  set iconUrl "http://fossil-scm.org/index.html/logo";

  set quer [tclInvoke http::formatQuery token  channel
"#tickets" username "Fossil" text $msgText icon_url $iconUrl]

  set token [tclInvoke http::geturl $url -method POST -timeout 3 -query
$quer]

  set status [tclInvoke http::status $token]

  tclInvoke http::cleanup $token
  tclInvoke http::unregister https
}

===

Easy enough!

The issue with this is that we need to set the $uuid variable from the C
implementation prior to invoking the script.  The issue is slightly
trickier for commit notifications (the Admin->Transfers->Push case), since
we can receive multiple artifacts in one Push operation.  I opted to
provide a list of UUIDs to a single invocation of the script, rather than
one UUID for each of multiple invocations.  This allows the script more
flexibility.  (Right now the variable is called $uuid rather than e.g.
$uuidList, which is something I can fix if the devs like the general
approach.)

Critiques are certainly welcome.  Mathematicians say, "never trust any
proof written after 11pm" -- this probably should be extended to code. :-)

If the devs think the patch has merit, then I'll be happy to add comments
etc.

It was a pleasure as always to do a bit of work on a DRH project.  DRH's
code has the all-too-rare property that what you think will work, usually
_does_ work -- the first time -- even if you are brand new to the code.
This is *way* harder than it looks.

If the patch is accepted, then I think it will more easily allow future
official support of Fossil from Slack, FWIW.  See this list:
https://slack.com/integrations .  It would be nice to see some little
dino-bones on that page.

Here's the patch, which is against Fossil 1.29 [3e5ebe2b90]:

===
--- fossil-src-20140612172556.orig/src/tkt.c2014-06-12
13:33:27.0 -0400
+++ fossil-src-20140612172556/src/tkt.c 2014-09-04 21:26:41.743216346 -0400
@@ -317,23 +317,24 @@
 void ticket_init(void){
   const char *zConfig;
   Th_FossilInit(TH_INIT_DEFAULT);
   zConfig = ticket_common_code();
   Th_Eval(g.interp, 0, zConfig, -1);
 }

 /*
 ** Create the TH1 interpreter and load the "change" code.
 */
-int ticket_change(void){
+int ticket_change(const char* zUuid){
   const char *zConfig;
   Th_FossilInit(TH_INIT_DEFAULT);
+  Th_SetVar(g.interp, "uuid", -1, zUuid, -1);
   zConfig = ticket_change_code();
   return Th_Eval(g.interp, 0, zConfig, -1);
 }

 /*
 ** Recreate the TICKET and TICKETCHNG tables.
 */
 void ticket_create_table(

Re: [fossil-users] "how to use git to lose data"

[Stephan Beal]

On Fri, Sep 5, 2014 at 10:03 PM, Nico Williams 
wrote:

> To me the "designed to forget" comments seem like a
> stretch.
>

git branch -D name

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users