Re: [fossil-users] Why no EXE+DLL like SQLite?
On 07/08/2018 03:21, Ron W wrote: I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think non-programmers would be unwilling to put up with it. As a simpler alternative, the "GUI" could just be implemented as an extension to Windows Explorer, where users would just right-click a folder to perform the main tasks provided by Fossil (commit, gdiff, etc.) ___ 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] Why no EXE+DLL like SQLite?
On Mon, Aug 6, 2018 at 12:57 PM wrote: > Date: Mon, 6 Aug 2018 11:18:09 -0500 > From: Artur Shepilko > Subject: Re: [fossil-users] Why no EXE+DLL like SQLite? > Message-ID: > > How would you want to use such a GUI? > I mean practically what is a non-programmer user workflow that > involves a VCS interaction via GUI? > ... > So my feeling is that no amount of explanation or "instructions" would > convert such users to make use of a VCS in any form, GUI or not. VCS > would be perceived as an additional and annoying hoop to jump through. > > So I wonder, how do you see your use-cases and GUI VCS workflow? > In the case of my employer, transitioning away from a hugely expensive (as in a large annual license fee) to SVN. Most of the non-programmers like it much more than the old system. Partly because because a set of documents could be identified by project code and SVN revision number, instead of a list of document numbers and revision numbers. with the help of a Power Shell script from IT, each user has, on their PC, a workspace for each project they are working on. Then they use TortoiseSVN to (mostly) commit changes to their documents, sometimes to fetch older versions. Many of the users are now making almost daily commits, not just just when making official releases of their documents. Unfortunately, fossil - and other DVCSs - use less friendly version IDs than the revision numbers SVN uses. But, I suspect that, after using the old system, the non-programmers would have welcomed Fossil, even with its unfriendly version IDs - except for the lack of a GUI front end to add, commit and update the user's workspace. I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think non-programmers would be unwilling to put up with it. And I seriously doubt it's a project corporate IT departments would be willing to take on. (The Power Shell script I mentioned is very simple. It presents the user with a folder-and-file style interface to select a project, then creates a folder in the user's projects folder and does a SVN checkout into that folder. I suspect most corporate IT directors would choose SVN+TortoiseSVN for a document management system for non-programmers, as an alternative to the kind document management system my employer used to use. If they did choose a DVCS, then I think it would be Mercurial+TortoiseHg or git+Tortoisegit, before they'd consider Fossil. (As I've mentioned before, my fellow programmers and I, use Fossil for our day-to-day VCS needs and only use SVN for official releases. We used to use SVN for day-to-day use, but then the "process gurus" decided to link SVN to an issue tracking system that makes every commit a 2 hour (or more) task. We use Fossil "under the radar" and the process gurus seem to think that our reduced use of SVN is a good thing, so haven't asked why we are using it less.) ___ 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] Why no EXE+DLL like SQLite?
On Mon, Aug 6, 2018 at 8:07 AM
wrote:
>
> Date: Mon, 6 Aug 2018 09:18:56 +0800
> From: Steve Landers
> Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
>
> Put differently, what can’t you do with “fossil ui” that you can do with a
> native client?
>
You can't do:
fossil add
fossil ci
fossil changes
fossil extras
and a few others.
With some IDEs, you can define an interface to the above commands, which
will run the command in a terminal (or command) window using command
templates you define.
For example:
fossil add ${selected_resource_path}
will tell Eclipse to run the "fossil add" command with the workspace
relative path of the currently selected file.
___
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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 8/6/18, joerg van den hoff wrote: > this is a pure > CLI/ssh scenario. The ssh transport works by invoking the same HTTP processing engine as is used on a website, just on the far end of an ssh tunnel. It's all the same under the covers. That said, I do remember making some minor changes to the ssh transport as part of the refactoring that is currently taking place. Maybe something broke. Can you bisect back to the last release and figure out where the problem was introduced? That would be a big help. > overall, I really hope that not too much complexity is currently added > to fossil that could lead to a situation where fossil no longer excels > by ease of use and stability/absence of problems or serious bugs as it > has done now for so many years, thankfully. There is a lot of refactoring going on right now, in an effort to avoid introducing unnecessary complexity. -- 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] Error during commit
On Aug 6, 2018, at 11:30 AM, Philip Bennefall wrote: > > a second commit right afterwards caused a segfault again In advance of drh getting time to work on this, maybe you could give two debugging steps on your end: 1. If you’re doing this on a platform that will run Valgrind, try running a debug build of Fossil under it against your repository: $ cd /path/to/fossil/source/tree $ ./configure --fossil-debug $ make clean && make && sudo make install $ cd /path/to/checkout/directory $ valgrind fossil status 2. If you get a vgcore out of that, load it into GDB and produce a backtrace. If not, cores are probably disabled there, so run Fossil under gdb and get a backtrace that way. (The first way is more likely to give a clean backtrace, as the failure gets caught before it can cause damage.) ___ 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's (lack of) use of the Ticket system
On 2018-08-04 4:48 AM, Gilles wrote: It might, since forum softwares (should) provide "sticky posts" that are displayed at the top. The one trick I've seen that seems most effective is to integrate the search function with the New Topic function such that the user is presented with a dynamic drop-down of suggested posts while typing their subject line. People accustomed to that behavior in Google search may find it natural to select an existing subject text to see what's there. Shal Farley Cheshire Engineering Corporation +1 626 303 1602 http://www.CheshireEng.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] Why no EXE+DLL like SQLite?
On Aug 5, 2018, at 2:14 PM, Gilles wrote: > > 1. SQLite is a DLL + EXE package A great many programs have need for an embedded DBMS. Very few programs have need for an embedded DVCS. Note also that these are empirical observations, rather than opinions. > 2. There's no maintained GUI for Fossil. Looking for a project? :) ___ 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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 06.08.18 22:19, Richard Hipp wrote:
> Here is the technical problem I am having difficulty with. My
> currently solution is (probably) what is causing the delays and errors
> you are seeing. Suggestions from you are any mailing list reader on
> how to solve this problem are appreciated.
I've read through your explanations below but there are sure no
suggestion from my side... I hardly understand the nature of the
problem. especially I am at a loss where all this backoffice machinery
interferes with CLI/ssh communication between two repos (or cloning, see
below).
however, I would like to augment the list of problems I am experiencing
right now (this is with version [71260ba2] as proposed by you earlier
today):
* fossil uv sync no longer works correctly. I did try it this evening
(still accessing our server via ssh but now over the wire from home
rather than from wihtin the file system (if this makes any difference)
and was not able to get one new uv file that was added to the server
repo sync to my labtop.
* I then tried to re-clone the whole repo. cloning failed completely with
multiple calls to backoffice_run() received: 113
server did not reply
Clone done, sent: 676 received: 364935 ip: {our_server}
server returned an error - clone aborted
I also want to emphasize that these problems all happen without ever
opening the fossil ui or trying to communicate via https. this is a pure
CLI/ssh scenario.
so this all is rather bad. it is also the first time in years that I can
remember that the tip of trunk is not working essentially without any
serious problems.
I would appreciate being pointed to the most recent (or thereabouts)
checkin on trunk that is not experiencing these problems in order to
get fossil back to working as nicely as it usually does.
If I can provide any further information or help otherwise in tracking
the present problems down, I would of course be happy to do so.
overall, I really hope that not too much complexity is currently added
to fossil that could lead to a situation where fossil no longer excels
by ease of use and stability/absence of problems or serious bugs as it
has done now for so many years, thankfully.
thank you,
joerg
>
> Basically: Fossil needs to run some operations in the background.
>
> With the introduction of email notification, some computations need to
> be performed in the background on the Fossil server. Right now, the
> only background operation is sending email alerts to subscribers. In
> the future, I'll probably want to add automatic synchronization to
> peer servers and maybe other things.
>
> I call the module that does background processing the "backoffice".
> The name comes from the analogy of a business where an order is placed
> at the counter in the front of the store, but the actually fulfillment
> of the order takes place in the "back office", out of sight of the
> customer.
>
> Backoffice rules:
>
> (1) Only a single process should be running backoffice processing at a
> time. There can be multiple processes serving up web pages, but there
> is only a single process sending email notification. Serialization of
> backoffice processing is handled by making atomic updates to the entry
> in the repository CONFIG table with name='backoffice'.
>
> (2) Backoffice processing should happen independently of webpage
> generation. The results of an HTTP request should not need to wait
> for some backoffice process to complete.
>
> (3) Once one backoffice process completes, no other should run for
> another 60 seconds or so. In other words, backoffice processes should
> be rate limited.
>
> (4) At least one backoffice process should be run within about 60
> seconds after the any successful HTTP request. A single backoffice
> run can satisfy this requirement for any number of HTTP requests. So,
> for example, if there is a flurry of 1000 HTTP requests then 5 seconds
> later there is a single backoffice run, then that one run of the
> backoffice is sufficient for all 1000 HTTP requests.
>
> (5) If there are no HTTP request in the past minute or two, then there
> should not be any backoffice processes running or waiting to run. The
> idea here is that a website like sqlite.org has literally about a
> hundred separate Fossil repositories. SQLite is very busy and it
> would be ok to have a persistent backoffice process running for it.
> But many of the other 99 repos are accessed much less frequently, and
> we don't want 99 processes waiting around for activity for days on
> end. Also, I want to be able to upgrade the Fossil executable by
> simply overwriting it, and then have any backoffice processes
> eventually (within a minute or two) switch over to using the new
> executable.
>
> (6) In keeping with the easy-to-setup goal of Fossil, running the
> backoffice process should not require any special setup or
> configuration by the site administrator. It should just work.
>
> The way the above is implemented
Re: [fossil-users] Error during commit
On 8/6/18, Philip Bennefall wrote: > But I wanted to report our experience in case it is of use to the > developers, and in case doing so could give us some assistance with the > immediate issue. Thank you for the report. This is definitely something that should be fixed. But I have a large queue of other issues of relevance to far more users (ex: support for email alerts and forum) that need to be fixed first. -- 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] Error during commit
The following command solved the issue at least for the moment: fossil rebuild --vacuum --analyze --compress I'm not yet sure which of the options made the difference, but I wanted to report back nevertheless. Kind regards, Philip Bennefall On 8/6/2018 6:57 PM, Philip Bennefall wrote: OK. I'll investigate. Thanks for the quick response. Kind regards, Philip Bennefall On 8/6/2018 6:50 PM, Richard Hipp wrote: On 8/6/18, Philip Bennefall wrote: Do you have any recommendations for something we could try in order to get more information, or would you suggest that we switch to another DVCS if we need to store files of these sizes? Regardless of the problem, I don't think *any* DVCS is appropriate for storing gigabyte sized binary files. You should look into a centralized VCS such as subversion, methinks. ___ 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] Error during commit
On 8/6/18, Richard Hipp wrote: > On 8/6/18, Philip Bennefall wrote: >> Do you have any recommendations for something we could try in order to >> get more information, or would you suggest that we switch to another >> DVCS if we need to store files of these sizes? > > Regardless of the problem, I don't think *any* DVCS is appropriate for > storing gigabyte sized binary files. You should look into a > centralized VCS such as subversion, methinks. Further information: Fossil was written for the purpose of managing the SQLite project. The primary SQLite Fossil repository contains about 5.8 GB of content when fully expanded, but that is compressed down to 92 MB. In other words, the whole repository spanning 18 years of development and 20K check-ins and 78K artifacts is less than 1/10th the size of just one of your files. The largest uncompressed artifact in the SQLite repo is 19 MB and the median uncompressed artifact size is 42 KB. With compression the largest artifact is 1.8 MB and median artifact size is a mere 152 bytes. I analyzed a bunch of other Fossil repositories, and they all mostly have similar stats. Except, usually the maximum uncompressed artifact size is about an order of magnitude less than 19 MB (SQLite is has a few exceptionally large artifacts) and in the case of the SQL Logic Test repository, the median artifact size was 1.5 KB. -- 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] Error during commit
OK. I'll investigate. Thanks for the quick response. Kind regards, Philip Bennefall On 8/6/2018 6:50 PM, Richard Hipp wrote: On 8/6/18, Philip Bennefall wrote: Do you have any recommendations for something we could try in order to get more information, or would you suggest that we switch to another DVCS if we need to store files of these sizes? Regardless of the problem, I don't think *any* DVCS is appropriate for storing gigabyte sized binary files. You should look into a centralized VCS such as subversion, methinks. ___ 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] Error during commit
On 8/6/18, Philip Bennefall wrote: > Do you have any recommendations for something we could try in order to > get more information, or would you suggest that we switch to another > DVCS if we need to store files of these sizes? Regardless of the problem, I don't think *any* DVCS is appropriate for storing gigabyte sized binary files. You should look into a centralized VCS such as subversion, methinks. -- 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] Error during commit
Do you have any recommendations for something we could try in order to get more information, or would you suggest that we switch to another DVCS if we need to store files of these sizes? Kind regards, Philip Bennefall On 8/6/2018 6:33 PM, Richard Hipp wrote: On 8/6/18, Philip Bennefall wrote: We have a repository in our organization which stores a number of rather large binary files. When attempting to commit, we sometimes get something like this: ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the repository My guess is that you are probably overflowing a 32-bit integer someplace. If so, I fear that this will not be something easily fixed. ___ 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] Error during commit
On 8/6/18, Philip Bennefall wrote: > We have a repository in our organization which stores a number of rather > large binary files. When attempting to commit, we sometimes get > something like this: > > > ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the > repository My guess is that you are probably overflowing a 32-bit integer someplace. If so, I fear that this will not be something easily fixed. -- 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] Why no EXE+DLL like SQLite?
How would you want to use such a GUI? I mean practically what is a non-programmer user workflow that involves a VCS interaction via GUI? The reason I ask, is that on several occasions I tried to convince "ordinary" users to incorporate a VCS into their daily tasks. Not just Fossil VCS, but Git and back in time SVN with GUI too. All of these attempts were unsuccessful, mainly due to lack of perceived utility. This gave me understanding that ordinary users deal with a different "revision" workflow than programmers. As the notion of a "project" often not clearly defined. Such users are often concerned with just a single Word document which then balloons to tie in a whole bunch of other resources. In such a setup a "change" representation is not what VCS's diff could produce. Also, there was not much of a need to retrieve previous states of such a document while the work is still in progress. Only after reaching a "final" version, such users would try to preserve the state before making "tweaks". This would be often done by creating a named copy (either of folder or just of TheFile). Collaborative use is slightly more convincing, yet even then the individual user workflow is still the same. The company backup policy takes over the VCS functions. Only one use-case, a "document tracking", was the most receptive. Mostly for the management and compliance convenience, not for the workflow. In such a case, tagging, searching and referencing were requested. So my feeling is that no amount of explanation or "instructions" would convert such users to make use of a VCS in any form, GUI or not. VCS would be perceived as an additional and annoying hoop to jump through. So I wonder, how do you see your use-cases and GUI VCS workflow? On Sun, Aug 5, 2018 at 3:55 PM, Gilles wrote: > Thanks for the info, but like 90% of deskop users, I run Windows. I gave up > on deskop Linux, even though I give it a try every year or so just to check > it out. > > I'm not arguing. It's just that Fossil is such a great SCM application that > I guess it would benefit even more users if it were available as a GUI > application instead of a CLI — which, I would venture, very few > non-developers, in this day and age, even know there is such as thing.) > > > On 05/08/2018 22:46, John Pateman wrote: > > Re Your point (2) > > There may not be a GUI for Windows (I don’t use Windows) but there is is a > nice ‘Tortoise-like’ GUI for Fossil on macOS - Snail Fossil. > > > On 5 Aug 2018, at 21:14, Gilles wrote: > > On 05/08/2018 22:02, Richard Hipp wrote: > > How does adding an extra component and a bunch of new interfaces make > a program easier to build? I think that the key to building complex > systems is to keep them as simple as possible. If you can omit a > DLL/shared library and all the maintenance and interface design > associated with it, then why wouldn't you? > > I was asking this naïve question because > 1. SQLite is a DLL + EXE package > 2. There's no maintained GUI for Fossil. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > ___ > 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] Error during commit
Additional information: The repo checksum is disabled locally. When enabling it, we get: Segmentation fault: 11 Kind regards, Philip Bennefall On 8/6/2018 6:11 PM, Philip Bennefall wrote: We have a repository in our organization which stores a number of rather large binary files. When attempting to commit, we sometimes get something like this: ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the repository The file in question was not modified during the given commit, but was checked in months ago. What can cause this, and what steps can we take to investigate? We are using Fossil 2.6. Thanks in advance for any help. Kind regards, Philip Bennefall ___ 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
[fossil-users] Error during commit
We have a repository in our organization which stores a number of rather large binary files. When attempting to commit, we sometimes get something like this: ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the repository The file in question was not modified during the given commit, but was checked in months ago. What can cause this, and what steps can we take to investigate? We are using Fossil 2.6. Thanks in advance for any help. Kind regards, Philip Bennefall ___ 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] strange delay and messages during `fossil (uv) sync'
On 8/6/18, joerg van den hoff wrote: > I see substantial delay (order of many seconds to minute(s)) when > executing > > seen with 2.6 [74c908e709] 2018-08-03 21:06:57 UTC > Please try https://www.fossil-scm.org/fossil/info/71260ba25e79f4aa and let me know whether or not that resolves the issue. -- 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] strange delay and messages during `fossil (uv) sync'
I see substantial delay (order of many seconds to minute(s)) when
executing
`fossil sync' or `fossil uv sync'
between a clone and a "remote" repository residing on the same file system and communicating via
ssh. the command finally succeeds and completes (but it really takes time...) with the message
multiple calls to backoffice_run() received: 0
server did not reply
done, sent: 660 received: 807 ip: {hostname}
I think this is closely related to
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27987.html
but might not be quite the same thing. so I thought it OK to report it again.
just in case...
seen with 2.6 [74c908e709] 2018-08-03 21:06:57 UTC
thank you
joerg
___
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] Why no EXE+DLL like SQLite?
On 6 Aug 2018, 9:19 AM +0800, Steve Landers , wrote: > Put differently, what can’t you do with “fossil ui” that you can do with a > native client? > > Drag and drop is the only one I can think of and I suspect that’s a good > thing. And also push notifications. While it can be done with web tech I don’t advocate it for fossil. Steve > On 6 Aug 2018, 9:17 AM +0800, Richard Hipp , wrote: > > On 8/5/18, Gilles wrote: > > > 2. There's no maintained GUI for Fossil. > > > > I would argue that running "fossil ui" is your GUI. > > > > -- > > 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 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] Why no EXE+DLL like SQLite?
I guess that's another reason why there's no desktop UI for fossil. It's just that I prefer desktop apps to web apps generally, but I can live with CLI + UI if there's nothing else. This thread was not meant as criticism; It was just a question. On 06/08/2018 03:18, Steve Landers wrote: Put differently, what can’t you do with “fossil ui” that you can do with a native client? Drag and drop is the only one I can think of and I suspect that’s a good thing. -- Steve On 6 Aug 2018, 9:17 AM +0800, Richard Hipp , wrote: On 8/5/18, Gilles wrote: 2. There's no maintained GUI for Fossil. I would argue that running "fossil ui" is your GUI. -- 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 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
