Re: [fossil-users] Tracking System Configuration Files - Best Practices
Could i convince one of the devs more familiar with the symlinks bits refine Joerg's explanation below into one of the embedded docs? It's a pretty good explanation/summary, IMO. On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 19:45:01 +0200, Matt Welland estifo...@gmail.com wrote: FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. I'm not sure whether there is a bug here (except the one noted at the end of this mail). my reading of `fossil help set' and a small test I've done right now with This is fossil version 1.29 [5e47d555e4] 2014-04-30 16:35:21 UTC (note to developers: the `This is' in the version message should go away in my view -- at least it would allow more seamless copy+paste not disrupting the syntax of the text into which one copies ;-)) seems to verify this behaviour: 1. allow-symlinks off (default): a) if the symlinks are ADDed and checkedin, content is tracked across the links, i.e. as far as fossil is concerned everything acts as if the actual files where local to the repo: changes are noted, checkouts overwrite the actual files, not the symlinks. this seems in accord with the documentation and sure is useful for the purpose of tracking disseminated config files, e.g. b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. 2. allow-symlinks on: a) if the symlinks are ADDed and checkedin, content is NOT tracked across the links, i.e. modifications of the linked files are not noticed by fossil and cannot be checked in. the content of the checkedin links (e.g. what you see with `fossil cat') just is the path to the linked files. this seems in accord with the documentation b) if this repo is cloned and opened, links materialize using verbatim the path stored as content in the original repo. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. j. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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 -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only
Re: [fossil-users] Tracking System Configuration Files - Best Practices
I was asked off the list to share what I ended up using. It was really quite simple in the end. I somehow missed the setting allow-symlinks. With this turned on, I just create symbolic links in the local tree and now, on the rare occasions that I pull, the link ins't wiped out, but the file pointed to be the link is updated. I can foresee the permission issues mentioned by others, but I rarely pull, so I hope I can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. Thanks for all your replies. Joseph ___ 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] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 5:30 PM, Joseph Mingrone j...@ftfl.ca wrote: can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. If that works, great :). i think that's the first time anyone's reported a painless solution to that problem - thanks for letting us know. -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 17:30:02 +0200, Joseph Mingrone j...@ftfl.ca wrote: I was asked off the list to share what I ended up using. It was really quite simple in the end. I somehow missed the setting allow-symlinks. With this turned on, I just create symbolic links in the local tree and now, on the rare occasions that I pull, the link ins't wiped out, but I don't think that this is the difference between allow-symlinks 'on' and 'off'? the link seems to be _never_ wiped out (independent of that setting), but when the setting is 'on' `fossil' just does not care for the actual content of the file the link points to (notably, it will not show anything with `fossil changes' even if the link(ed file) is modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? the file pointed to be the link is updated. I can foresee the permission issues mentioned by others, but I rarely pull, so I hope I can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. Thanks for all your replies. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.comwrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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] Tracking System Configuration Files - Best Practices
FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 19:45:01 +0200, Matt Welland estifo...@gmail.com wrote: FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. I'm not sure whether there is a bug here (except the one noted at the end of this mail). my reading of `fossil help set' and a small test I've done right now with This is fossil version 1.29 [5e47d555e4] 2014-04-30 16:35:21 UTC (note to developers: the `This is' in the version message should go away in my view -- at least it would allow more seamless copy+paste not disrupting the syntax of the text into which one copies ;-)) seems to verify this behaviour: 1. allow-symlinks off (default): a) if the symlinks are ADDed and checkedin, content is tracked across the links, i.e. as far as fossil is concerned everything acts as if the actual files where local to the repo: changes are noted, checkouts overwrite the actual files, not the symlinks. this seems in accord with the documentation and sure is useful for the purpose of tracking disseminated config files, e.g. b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. 2. allow-symlinks on: a) if the symlinks are ADDed and checkedin, content is NOT tracked across the links, i.e. modifications of the linked files are not noticed by fossil and cannot be checked in. the content of the checkedin links (e.g. what you see with `fossil cat') just is the path to the linked files. this seems in accord with the documentation b) if this repo is cloned and opened, links materialize using verbatim the path stored as content in the original repo. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. j. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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 -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. FWIW, i've had to struggle with that question in libfossil and i (currently) feel that the current behaviour follows the Principal of Least Surprise, in that it's consistent: no symlinks means no symlinks. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. Doesn't that mean that it supports both relative and absolute, and it's up to the user to choose which one he wants? There are use cases for both, IMO. (That said, i never was a big fan of having symlink support in fossil!) -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. FWIW, i've had to struggle with that question in libfossil and i (currently) feel that the current behaviour follows the Principal of Least Surprise, in that it's consistent: no symlinks means no symlinks. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. Doesn't that mean that it supports both relative and absolute, and it's up to the user to choose which one he wants? There are use cases for both, I agree. there is no best choice here. IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 9:02 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. That's what has always bothered me about the symlinks support: it's inherently non-portable, opens up tricky questions about how it should behave, and it might be handy for some (it's not generally needed - i've never used it, and never missed it). i do, however, agree that (like diff-follows-rename) if you have a need for it, it's a handy feature to have. -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 21:07:59 +0200, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:02 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. That's what has always bothered me about the symlinks support: it's inherently non-portable, opens up tricky questions about how it should behave, and it might be handy for some (it's not generally needed - again agreed. but it does no harm to have it (as long as one does not demand too much of it). i've never used it, and never missed it). i do, however, agree that (like diff-follows-rename) if you have a need for it, it's a handy feature to the diff-follows-rename problem seems in a different league for me. and the how it should behave issue has a clear answer in this case (at least there would be a clear majority vote ;-)) have. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Tracking System Configuration Files - Best Practices
On Mon, Apr 28, 2014 at 10:15 PM, Joseph Mingrone j...@ftfl.ca wrote: Thank you all for taking the time to share your thoughts. Since I won't be moving these files around too often, I think I will give Fossil (along with Tripwire) a go at this. Does Fossil have something equivalent to another_unamed_scm config core.worktree ../../ which allows you to separate the repository from the source tree? No - the checkout db MUST currently be in the top-most checkout dir. In developing libfossil i have seen that this limitation is purely one of convenience, and one of the eventual features will be to allow the checkout db and its files to live in different places. That said, it will be some time before that's implemented because much cause assumes that checkout db is in the top-most source tree (in fact, that's how fossil finds the checkout in the first place, and it's not clear how that convenience could be implemented if they are separate). -- - 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] Tracking System Configuration Files - Best Practices
Thank you all for taking the time to share your thoughts. Since I won't be moving these files around too often, I think I will give Fossil (along with Tripwire) a go at this. Does Fossil have something equivalent to another_unamed_scm config core.worktree ../../ which allows you to separate the repository from the source tree? Joseph ___ 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] Tracking System Configuration Files - Best Practices
On 4/28/2014 3:15 PM, Joseph Mingrone wrote: Thank you all for taking the time to share your thoughts. Since I won't be moving these files around too often, I think I will give Fossil (along with Tripwire) a go at this. Does Fossil have something equivalent to another_unamed_scm config core.worktree ../../ which allows you to separate the repository from the source tree? Perhaps I misunderstand your question, but Fossil already separates your repository database file from your checkout directory. mkdir -p repos checkout fossil new repos/project.fossil cd checkout fossil open ../repos/project.fossil -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tracking System Configuration Files - Best Practices
On Thu, Apr 24, 2014 at 12:23:29AM -0400, Ron Wilson wrote: On Wed, Apr 23, 2014 at 9:38 AM, Will Parsons varro@nodomain.invalidwrote: This kind of stuff isn't a project, and you don't need the extra stuff that Fossil (or Git, Mercurial, Bazaar, Subversion, or CVS) provide. I've tracked system files for over a decade with RCS (and before that with SCCS) and see no reason to change. I disagree. Very often system changes have to be coordinate across several config files. Most distributions have admin tools to take care of this, but don't track the history of the changes. For most uses, this is fine. Where I work, the IT people already use a tool like Tripwire to monitor the status (including ownership and permissions) of system critical directories and files. Another part of this tool is used to reset the permissions, ownership, etc of these files when changes are made. Because of this, they can - and do - use Fossil to track system configuration changes. By using this combination of distribution provided tools, a few custom tools, the Tripwire like tool and Fossil, they actually have more and better control of configuration. And they save the company several $10k per year in licensing fees for commercial system management suites. What are the chances you could produce a description of how this setup is used such that it would provide a howto for setting up similar systems in other people's networks, or convince someone else to write such a thing? This could make for an excellent article somewhere. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Tracking System Configuration Files - Best Practices
On Tue, Apr 22, 2014 at 5:55 PM, Joseph Mingrone j...@ftfl.ca wrote: Is Fossil an appropriate tool for tracking system configuration files? For for user-specific ones, IMO, and then not for everything, e.g. SSH likes certain files to have certain permissions, and fossil does not do permissions except for the +x bit. Some people have tried to use fossil to store stuff from /etc before, but they have always ended up requiring extra scripts to fix permissions/ownership (fossil only knows, in effect, a single user, and that is you). Summary: it's not the right tool for the job of storing system-level config files, primarily (IMO) because of ownership/permissions. -- - 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
