Re: [fossil-users] fossil for web site maintenance [was how to use git to lose data]
On 06/09/14 17:03, Richard Hipp wrote: 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.) I have a related kind of setup at https://www.kitten-technologies.co.uk/ The top-level site is static HTML (but generated via scripts from master content in a fossil repo). However, there are a number of fossil repos for different projects, which are invoked via fossil-as-cgi. https://www.kitten-technologies.co.uk/project/kitten-technologies is the project that generates the master site, which includes the cgi thingies! Eg, /project/kitten-technologies itself comes from https://www.kitten-technologies.co.uk/project/kitten-technologies/artifact/cdeb6789a25bed09afebb6c4f8577a5fc00ad349 And I've hacked the CSS around like crazy to all refer to the central stuff. Per-repo stuff like the skin gets rolled out from the central configuration by a script. It... works! And keeps down the maintenance cost for me of a heap of fossil repos for my crazy open-source outpourings. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ 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 for web site maintenance [was how to use git to lose data]
Thanks! Not tedious at all - details are appreciated! Scott Robison wrote: On Sat, Sep 6, 2014 at 9:52 AM, Miles Fidelman mfidel...@meetinghouse.net mailto:mfidel...@meetinghouse.net 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 http://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 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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 wrote: On Sat, Sep 6, 2014 at 12:47 PM, Miles Fidelman mfidel...@meetinghouse.net mailto:mfidel...@meetinghouse.net 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. Yes, but what I'd really like is an embedded wiki, that operates like a wiki - but with distributed editing, merges, updates, etc. Seems like the fossil embedded wiki provides half of that, embedded documentation the other. Sigh... Oh well. Or am I missing something about the embedded documentation? Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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]
On Sun, Sep 7, 2014 at 4:30 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Yes, but what I'd really like is an embedded wiki, that operates like a wiki - but with distributed editing, merges, updates, etc. Seems like the fossil embedded wiki provides half of that, embedded documentation the other. Sigh... Oh well. Or am I missing something about the embedded documentation? Right now, Fossil will provide regular wiki pages or embedded wiki pages. Regular wiki pages can be edited via the web interface. But, currently, conflicting edits result in forks, which are viewable in the time line, just no easy way to do proper branching and merging. Embedded wiki pages act like regular wiki pages (since they are wiki pages). Also, they can be easily branched and merged. But editing them is done the same way you edit your project source files, externally to Fossil, then the changes committed. Fossil does provide a way to preview these pages before committing them. People have expressed interest in adding support for branching and merging regular wiki pages. The hold up is the how. ___ 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 wrote: On Sun, Sep 7, 2014 at 4:30 PM, Miles Fidelman mfidel...@meetinghouse.net mailto:mfidel...@meetinghouse.net wrote: Yes, but what I'd really like is an embedded wiki, that operates like a wiki - but with distributed editing, merges, updates, etc. Seems like the fossil embedded wiki provides half of that, embedded documentation the other. Sigh... Oh well. Or am I missing something about the embedded documentation? Right now, Fossil will provide regular wiki pages or embedded wiki pages. Regular wiki pages can be edited via the web interface. But, currently, conflicting edits result in forks, which are viewable in the time line, just no easy way to do proper branching and merging. Embedded wiki pages act like regular wiki pages (since they are wiki pages). Also, they can be easily branched and merged. But editing them is done the same way you edit your project source files, externally to Fossil, then the changes committed. Fossil does provide a way to preview these pages before committing them. People have expressed interest in adding support for branching and merging regular wiki pages. The hold up is the how. Is anybody actually thinking about that, or working on it? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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]
Scott Robison wrote: On Tue, Sep 2, 2014 at 2:44 AM, Gour g...@atmarama.net mailto:g...@atmarama.net 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
Re: [fossil-users] fossil for web site maintenance [was how to use git to lose data]
On Sat, Sep 6, 2014 at 11:52 AM, Miles Fidelman 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.) 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
Re: [fossil-users] fossil for web site maintenance [was how to use git to lose data]
Richard Hipp wrote: On Sat, Sep 6, 2014 at 11:52 AM, Miles Fidelman mfidel...@meetinghouse.net 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]
On Sat, Sep 6, 2014 at 9:52 AM, Miles Fidelman mfidel...@meetinghouse.net 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] fossil for web site maintenance [was how to use git to lose data]
On Sat, Sep 6, 2014 at 12:47 PM, Miles Fidelman mfidel...@meetinghouse.net 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
