[fossil-users] FOSSIL ALL
I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. But there is no easy way to find out which repos are currently open – so, I must explicitly visit each subdirectory, run a command like FOSSIL CHANGES to get a message whether the repo is open or not. Perhaps FOSSIL ALL LIST (or LS) could also show the status of the related repo. Something like: FOSSIL ALL LIST /somepath/a.fossil /otherpath/b.fossil (OPEN) /who/knows/where/path/c.fossil /temp/d.fossil /whatever/e.fossil (OPEN) And, how about a command to close all open repos at once, e.g., at the end of the day? FOSSIL ALL CLOSE should of course stop at the first repo that has, say uncommitted changes, the same way a FOSSIL CLOSE does, unless a –FORCE option is used. Thanks. ___ 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 ALL
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote: I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. Close them? Why do you want to do that? It seems to me that all you really need to do is ensure that all changes have been committed, which can be accomplished using fossil all changes. Presumably, all of your repos have a default sync partner - probably a master repository on a server someplace. (At least, that is the way I work things. I have 35 projects currently going on my desktop, all of which are mirrored on one of two servers I control in the cloud.) In that case, all you need to do before leaving work is fossil all changes to look for uncommitted changes. Then when you get to home, just do fossil al sync to pull all the changes from work down to your home machine. Nothing needs to be closed. When heading back to work, just do fossil all changes on your home machine to make sure you have committed everything, then fossil all sync when you get back to the office. The scenario above is exactly why I invented fossil all. :-) -- 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 ALL
Actually, FOSSIL ALL LIST shows all repos, including the closed ones. If it only showed the open ones, half of my problem would be solved (although a new one would be created – how to see all repos installed on a given machine). Regarding the rest of your comments please see my response to Dr Hipp. From: Stephan Beal That won't (or shouldn't) work because once a repo is closed it will (or should) no longer show up in the 'all' list. ___ 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 ALL
OK, maybe I have a misunderstanding of the need for close. What is it used for? The claim by Stephan Beal that he hasn’t closed a repo more than 5 times over many years makes me wonder why is there even a CLOSE command? In my case, there is no server used, because this is private work that I cannot trust to be placed on any public server since I do not want anyone to have access to it (and by anyone I include the owner of the public server). I have thought about setting up a server on one of the two machines (home or office) but that would require one of these computers to be always on, which again I would rather not have. So, in my case, my only alternative is to move the fossil file from computer to computer – so that the ‘master’ relocates all the time between two points. And, proper procedure for most applications would be to close a file, transfer it, and then re-open it. But, maybe fossil is more lenient... I don’t know. So, are you saying, that if I keep both repo versions (work and home) open all the time, and simply copy over (from the backup) the related fossil files, there won’t be any corruption on either site? And, I suppose instead of open (at the start of the day), I should be doing what exactly? FOSSIL REV to update the current checkout from the just updated FOSSIL file which would appear like a revert on the other side? Or, an UPDATE? And, what if I’m on different branches? Is this guaranteed to work correctly without creating any unpleasant side effects, from simple forks, etc., to the most serious of which would be a corruption of the repo and loss of work (and not only one day’s)? OK, maybe I do not need the functionality I asked for but can someone explain what would be the equivalent work flow between two different machines where there is no common server, and the FOSSIL file is at any moment replaced with a new file (from the other machine?) Currently, my process is this: LOOP: FOSSIL OPEN ... code changes ... FOSSIL COMMIT FOSSIL CLOSE transfer repo file to other machine, and copy it over the previous version goto LOOP From: Richard Hipp Sent: Monday, October 27, 2014 1:11 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FOSSIL ALL On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote: I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. Close them? Why do you want to do that? It seems to me that all you really need to do is ensure that all changes have been committed, which can be accomplished using fossil all changes. Presumably, all of your repos have a default sync partner - probably a master repository on a server someplace. (At least, that is the way I work things. I have 35 projects currently going on my desktop, all of which are mirrored on one of two servers I control in the cloud.) In that case, all you need to do before leaving work is fossil all changes to look for uncommitted changes. Then when you get to home, just do fossil al sync to pull all the changes from work down to your home machine. Nothing needs to be closed. When heading back to work, just do fossil all changes on your home machine to make sure you have committed everything, then fossil all sync when you get back to the office. The scenario above is exactly why I invented fossil all. :-) -- 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] fossil diff --tk hangs when there are no changes
Suppose it's Monday morning (like...5 minutes ago) and you committed all your changes on Friday afternoon. You come in on Monday and use the handy `fossil diff --tk` feature to see if you left anything uncommitted last week. When there are no outstanding changes and you `fossil diff --tk`, it just hangs. I think the software should behave as it does for `fossil diff`, which just quits. Note that one could also argue for a message like No differences between checkout and repository to be printed to the console, perhaps on stderr, in order to give more situational awareness. Thanks! ___ 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 ALL
I guess the same scenario would be valid if one used a server but had private branches. My understanding is that private branches do not sync so the only way to move to another location is to move the whole fossil file. Correct? From: Tony Papadimitriou Sent: Monday, October 27, 2014 1:48 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FOSSIL ALL OK, maybe I have a misunderstanding of the need for close. What is it used for? The claim by Stephan Beal that he hasn’t closed a repo more than 5 times over many years makes me wonder why is there even a CLOSE command? In my case, there is no server used, because this is private work that I cannot trust to be placed on any public server since I do not want anyone to have access to it (and by anyone I include the owner of the public server). I have thought about setting up a server on one of the two machines (home or office) but that would require one of these computers to be always on, which again I would rather not have. So, in my case, my only alternative is to move the fossil file from computer to computer – so that the ‘master’ relocates all the time between two points. And, proper procedure for most applications would be to close a file, transfer it, and then re-open it. But, maybe fossil is more lenient... I don’t know. So, are you saying, that if I keep both repo versions (work and home) open all the time, and simply copy over (from the backup) the related fossil files, there won’t be any corruption on either site? And, I suppose instead of open (at the start of the day), I should be doing what exactly? FOSSIL REV to update the current checkout from the just updated FOSSIL file which would appear like a revert on the other side? Or, an UPDATE? And, what if I’m on different branches? Is this guaranteed to work correctly without creating any unpleasant side effects, from simple forks, etc., to the most serious of which would be a corruption of the repo and loss of work (and not only one day’s)? OK, maybe I do not need the functionality I asked for but can someone explain what would be the equivalent work flow between two different machines where there is no common server, and the FOSSIL file is at any moment replaced with a new file (from the other machine?) Currently, my process is this: LOOP: FOSSIL OPEN ... code changes ... FOSSIL COMMIT FOSSIL CLOSE transfer repo file to other machine, and copy it over the previous version goto LOOP From: Richard Hipp Sent: Monday, October 27, 2014 1:11 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FOSSIL ALL On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote: I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. Close them? Why do you want to do that? It seems to me that all you really need to do is ensure that all changes have been committed, which can be accomplished using fossil all changes. Presumably, all of your repos have a default sync partner - probably a master repository on a server someplace. (At least, that is the way I work things. I have 35 projects currently going on my desktop, all of which are mirrored on one of two servers I control in the cloud.) In that case, all you need to do before leaving work is fossil all changes to look for uncommitted changes. Then when you get to home, just do fossil al sync to pull all the changes from work down to your home machine. Nothing needs to be closed. When heading back to work, just do fossil all changes on your home machine to make sure you have committed everything, then fossil all sync when you get back to the office. The scenario above is exactly why I invented fossil all. :-) -- 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] fossil diff --tk hangs when there are no changes
New test version contained in branch: tk-diff-viewer, behaves in the following way: http://fossil-scm.org/index.html/info/cbd4dca6807d95d73c22cb02893887efc1b51655 When there are no changes, the GUI opens with void differences and a message in a window informs the user: No changes. In this way, it is possible to use the new commands of the interface like: Older version and Newer version RR 2014-10-27 13:10 GMT+01:00 Sean Woods s...@seanwoods.com: Suppose it's Monday morning (like...5 minutes ago) and you committed all your changes on Friday afternoon. You come in on Monday and use the handy `fossil diff --tk` feature to see if you left anything uncommitted last week. When there are no outstanding changes and you `fossil diff --tk`, it just hangs. I think the software should behave as it does for `fossil diff`, which just quits. Note that one could also argue for a message like No differences between checkout and repository to be printed to the console, perhaps on stderr, in order to give more situational awareness. Thanks! ___ 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] FOSSIL ALL
On Mon, Oct 27, 2014 at 12:48 PM, Tony Papadimitriou to...@acm.org wrote: OK, maybe I have a misunderstanding of the need for close. What is it used for? The claim by Stephan Beal that he hasn’t closed a repo more than 5 times over many years makes me wonder why is there even a CLOSE command? All close does is: a) removes the .fslckout resp. _FOSSIL_ file from the checkout b) it should (IMO, if it doesn't already) remove the checkout from the all list (kept in the global config db). Thinking over it now, i confused repos and checkouts with regard to the all list - when closing a checkout, the _checkout_, not the repo, should (IMO) be removed from the all list. Primarily 'close' is only used to remove the fossil crud from the tree (the checkout db file), e.g. before ZIPping it up for distribution by a client (but fossil supports zip/tar out of the box, so 'close' has even fewer real uses). In my case, there is no server used, because this is private work that I cannot trust to be placed on any public server since I do not want anyone to have access to it (and by anyone I include the owner of the public server). I have thought about setting up a server on one of the two machines (home or office) but that would require one of these computers to be always on, which again I would rather not have. So, in my case, my only alternative is to move the fossil file from computer to computer – so that the ‘master’ relocates all the time between two points. And, proper procedure for most applications would be to close a file, transfer it, and then re-open it. But, maybe fossil is more lenient... I don’t know. If you are working by manually copying the repo dbs, then close is probably a good thing to do, to avoid any side effects with blob IDs being different between your checkout copies. That's an unusual use case for Fossil, though - most users have a central copy, either available via CGI, on a network drive, or similar (that said: network drives are not recommended for this purpose - there are historically many problems involving file locking over network shares). If you have the option to host CGI scripts, i can strongly recommend moving the repo to your CGI hoster and accessing it over the network. Most internet providers offer CGI script support in their package, so if you have a hoster already then you likely have this option. So, are you saying, that if I keep both repo versions (work and home) open all the time, and simply copy over (from the backup) the related fossil files, there won’t be any corruption on either site? Better not do that. If you really are copying around the repo dbs, it's safest (IMO) to close them before copying them around. Not strictly required, but not a bad idea. And, I suppose instead of open (at the start of the day), I should be doing what exactly? FOSSIL REV to update the current checkout from the just updated FOSSIL file which would appear like a revert on the other side? In the normal case you'd do: fossil update But in your case i think that 'open' is the right approach (for a given definition of right ;). Or, an UPDATE? And, what if I’m on different branches? Is this guaranteed to work correctly without creating any unpleasant side effects, from simple forks, etc., to the most serious of which would be a corruption of the repo and loss of work (and not only one day’s)? fossil update BRANCH will merge as appropriate. Using open/close, i believe you are far more at risk for data loss than you would be using 'update.' OK, maybe I do not need the functionality I asked for but can someone explain what would be the equivalent work flow between two different machines where there is no common server, and the FOSSIL file is at any moment replaced with a new file (from the other machine?) Currently, my process is this: i would argue that that's not a use case fossil targets (or not a common setup). LOOP: FOSSIL OPEN ... code changes ... FOSSIL COMMIT FOSSIL CLOSE transfer repo file to other machine, and copy it over the previous version goto LOOP If you _must_ copy the repo files around, then the above loop is essentially the right way to do it (again, for a given definition of right ;). -- - 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 ALL
On Mon, Oct 27, 2014 at 8:30 AM, Stephan Beal sgb...@googlemail.com wrote: If you are working by manually copying the repo dbs, then close is probably a good thing to do, to avoid any side effects with blob IDs being different between your checkout copies. Yikes. I forgot about that. Stephan is right. On the other hand, if both copied repos sprang from the same origin and have always been copied and there the blob IDs will continue to be the same. Even so, using the clone to file: technique is probably much safer. -- 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 diff --tk hangs when there are no changes
On Mon, Oct 27, 2014 at 8:10 AM, Sean Woods s...@seanwoods.com wrote: Suppose it's Monday morning (like...5 minutes ago) and you committed all your changes on Friday afternoon. You come in on Monday and use the handy `fossil diff --tk` feature to see if you left anything uncommitted last week. Clearly problems in --tk need to be fixed. Nevertheless, the fossil all changes command might be a better way to accomplish what you are trying to do -- 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 diff --tk hangs when there are no changes
On Mon, Oct 27, 2014, at 08:25 AM, Ramon Ribó wrote: New test version contained in branch: tk-diff-viewer, behaves in the following way: http://fossil-scm.org/index.html/info/cbd4dca6807d95d73c22cb02893887efc1b51655 When there are no changes, the GUI opens with void differences and a message in a window informs the user: No changes. In this way, it is possible to use the new commands of the interface like: Older version and Newer version Thanks Ramon. Question: I downloaded the snapshot of fossil that Ramon did above and compiled it using MinGW (`./configure` followed by `make -f win/Makefile.mingw` from the msys bash shell within Windows). I can type `which tclsh` and get the tclsh located at `/usr/local/bin/tclsh` (again, this is within the msys environment). I can launch tclsh by simply typing it at the bash prompt. Unfortunately, when I run `fossil diff --tk` from the new fossil binary, it says it can't find the tclsh program. It worked before, with the old version of fossil (3e5ebe2b90). Ideas? ___ 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 ALL
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote: I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. Thinking about how to make this operation easier Are you using Linux, Mac, or Windows? -- 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 ALL
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote: I have several repos open at the same time, not always the same ones. Before I swap computers (home = work) I would like to close all open repos on one site, and take a backup to take to the other site. I wanted to add my two cents here because this is very similar to my current workflow. I'm currently in a Windows environment and don't have access to a server. Though I use fossil, I basically only use it in one repository. I have `c:\spw\fossils\projectname.fossil` that holds the main repository. Then I have a checkout in `c:\spw\code` I work in code, then `fossil commit` to send my changes to fossils. Problem, obviously, is that if this drive fails I'm totally hosed. So what I do is copy the repo from fossils to H:\ for backup purposes. H:\ is a network drive that contains my home folder on Windows. Periodically I use the copy command to copy the fossils repo over to H:\. This seems fine although I always get nervous I'll accidentally switch the arguments around or somehow otherwise delete the main repo. I would really like the option to autosync to another directory rather than a remote system. However, based on the sync documentation on the fossil web site, it seems since sync is HTTP based, so HTTP'ing to another dir is probably not an option. I suppose I could `fossil ui` or `fossil serve` from a checkout in the other repository and use sync that way, but there are lots of steps there. Also I saw in another thread the presence of a file:// URL scheme, but saw no mention of it in the sync documentation. If it does exist perhaps it's a solution for me. Is this related to what Tony P. is saying or am I completely in left field? ___ 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 ALL
On Mon, Oct 27, 2014 at 9:30 AM, Tony Papadimitriou to...@acm.org wrote: I use mostly Windows, but every so often I open the repo on a Linux box (but I can do without Linux for now). Most thing we get working on Linux first, as that is the primary desktop for most of the Fossil developers (Jan excepted) That said, I think the previously described system of syncing to your thumb-drive using the file: scheme is probably going to work best for you. To recap: (1) Run fossil all setting autosync off. (2) Make copies of all repos onto your thumb drive. (3) For each working check-out: (3a) fossil remote file:/path/to/repo/on/thumb/drive The above is a one-time setup. Now, to transfer, just plug in your thumb drive and do: fossil all sync Then take the thumb drive home and do fossil all sync there too (having previously done the same 3-step setup). I'm not exactly sure what the syntax for the the file: URL is for the D: or E: filesystem (or whatever your USB stick comes up as). And I'm away from the office and don't have access to a windows machine to test it. Some experimentation is in order, but once you get it working, it should just work. -- 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 ALL
On Mon, Oct 27, 2014 at 9:38 AM, Sean Woods s...@seanwoods.com wrote: Also I saw in another thread the presence of a file:// URL scheme, but saw no mention of it in the sync documentation. If it does exist perhaps it's a solution for me. I think it works. But to be clear, I don't use it myself so maybe it is busted without my knowledge. Give it a try. Report back if you have problems. -- 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 ALL
Thus said Tony Papadimitriou on Mon, 27 Oct 2014 14:18:04 +0200: I guess the same scenario would be valid if one used a server but had private branches. My understanding is that private branches do not sync so the only way to move to another location is to move the whole fossil file. Correct? From ``fossil help sync'': Use the --private option to sync private branches with the remote repository. Andy -- TAI64 timestamp: 4000544e69f0 ___ 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 ALL
Message: 7 Date: 27 Oct 2014 09:50:39 -0600 From: Andy Bradford amb-fos...@bradfords.org To: Tony Papadimitriou to...@acm.org Cc: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] FOSSIL ALL Message-ID: 20141027095039.14517.qm...@angmar.bradfordfamily.org Thus said Tony Papadimitriou on Mon, 27 Oct 2014 14:18:04 +0200: I guess the same scenario would be valid if one used a server but had private branches. My understanding is that private branches do not sync so the only way to move to another location is to move the whole fossil file. Correct? From ``fossil help sync'': Use the --private option to sync private branches with the remote repository. Andy -- TAI64 timestamp: 4000544e69f0 FWIW, I work mostly on windows. I'm pretty confident I have never explicitly used file://. I just say fossil clone U:/fossils/myfossil.fossil And fossil does the rest to put things in. Same for fossil remoteurl. I've used both relative and absolute paths to the fossil repo. Fossil automatically adds the file:// part as necessary. The way Richard described it will (should) work. As another FWIW, I have many repos on a network drive in '--wal' mode to share between windows / linux sources and have yet to have a corruption issue after a year and a half of not-so-frequent use. Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [PATCH] broken parsing of contact information in git export
Hello, Parsing of contact information in git export is totally broken. For example, if your contact information in fossil is Tomasz Konojacki m...@xenu.tk, it will be exported to git as Tomasz Kon m...@xenu.tk, when e-mail is longer than name results are even more bizarre. Patch is located at http://xenu.tk/fossil.patch Cheers, Tomasz ___ 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] [PATCH] broken parsing of contact information in git export
On Mon, Oct 27, 2014 at 7:38 PM, Tomasz Konojacki m...@xenu.tk wrote: Parsing of contact information in git export is totally broken. For example, if your contact information in fossil is Tomasz Konojacki m...@xenu.tk, it will be exported to git as Tomasz Kon m...@xenu.tk, when e-mail is longer than name results are even more bizarre. Patch is located at http://xenu.tk/fossil.patch Richard was faster: he had it checked in while i was still trying to figure out why changing a var name fixed it. -- - 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
