[fossil-users] Stash with renames
Hello, here 'fossil stash' behaved weird, if I had done 'fossil mv' operations. The renames remain in the 'fossil status' after stash, and it also caused a revert of all files in my repository; at elast that's what the console log said. Maybe 'fossil stash' should handle better the renames situation? It looks a bit broken. I've tried with the current fossil trunk; two renames + the fs file moves, and fossil starts a full revert file per file of all the repository. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Merging with renames (new directories)
Hello, running a fossil merge mybranch fails to create some files, if the merge includes renames to a directory non existant in the working copy. Creating those directories makes the merge work. I think that the handling of renames in the 'merge' operation does not handle creating directories for those renames. The output: ... UPDATE tools/tool1/src/CMakeLists.txt RENAME tools/tool1/src/lv/CMakeLists.txt - tools/tool2/src/lv/CMakeLists.txt /home/llbatlle/3rd/fossil/fossil: cannot open /home/llbatlle/a/repo/tools/tool2/src/lv/CMakeLists.txt for writing Stracing, it shows it's a open(...,O_CREAT,...) call failing with ENOENT. Tested with fossil trunk. Regards, Lluís. ___ 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] Merging with renames (new directories)
Dave, Have you performed this test with windows exceptions enabled? It is possible that the direct write to the log file I have added after Phoenix has updated is causing an undisplayed exception. This would leave you in a situation where the system update has been performed but the active manifest has not been written to resulting in exactly what you see...2 grey boxes appearing indicating that that the update is being performed but then the original Phoenix being executed after a restart. Bob -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Lluís Batlle i Rossell Sent: 03 July 2012 13:49 To: Fossil ML Subject: [fossil-users] Merging with renames (new directories) Hello, running a fossil merge mybranch fails to create some files, if the merge includes renames to a directory non existant in the working copy. Creating those directories makes the merge work. I think that the handling of renames in the 'merge' operation does not handle creating directories for those renames. The output: ... UPDATE tools/tool1/src/CMakeLists.txt RENAME tools/tool1/src/lv/CMakeLists.txt - tools/tool2/src/lv/CMakeLists.txt /home/llbatlle/3rd/fossil/fossil: cannot open /home/llbatlle/a/repo/tools/tool2/src/lv/CMakeLists.txt for writing Stracing, it shows it's a open(...,O_CREAT,...) call failing with ENOENT. Tested with fossil trunk. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ DISCLAIMER: Information contained in this email or any attachment may be of a confidential nature which should not be disclosed to, copied or used by anyone other than the addressee. It may also be legally privileged. If you receive this email in error, please delete the email from your computer and notify the sender immediately by return E-mail. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. Virus Warning: _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ ___ 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] Merging with renames (new directories)
Sorry guys, somehow outlook flipped messages on me while replying to a completely different email! Bob Bellchambers-Wilson -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Bob Bellchambers-Wilson Sent: 03 July 2012 14:05 To: Fossil SCM user's discussion Subject: Re: [fossil-users] Merging with renames (new directories) Dave, Have you performed this test with windows exceptions enabled? It is possible that the direct write to the log file I have added after Phoenix has updated is causing an undisplayed exception. This would leave you in a situation where the system update has been performed but the active manifest has not been written to resulting in exactly what you see...2 grey boxes appearing indicating that that the update is being performed but then the original Phoenix being executed after a restart. Bob -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Lluís Batlle i Rossell Sent: 03 July 2012 13:49 To: Fossil ML Subject: [fossil-users] Merging with renames (new directories) Hello, running a fossil merge mybranch fails to create some files, if the merge includes renames to a directory non existant in the working copy. Creating those directories makes the merge work. I think that the handling of renames in the 'merge' operation does not handle creating directories for those renames. The output: ... UPDATE tools/tool1/src/CMakeLists.txt RENAME tools/tool1/src/lv/CMakeLists.txt - tools/tool2/src/lv/CMakeLists.txt /home/llbatlle/3rd/fossil/fossil: cannot open /home/llbatlle/a/repo/tools/tool2/src/lv/CMakeLists.txt for writing Stracing, it shows it's a open(...,O_CREAT,...) call failing with ENOENT. Tested with fossil trunk. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ DISCLAIMER: Information contained in this email or any attachment may be of a confidential nature which should not be disclosed to, copied or used by anyone other than the addressee. It may also be legally privileged. If you receive this email in error, please delete the email from your computer and notify the sender immediately by return E-mail. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. Virus Warning: _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ DISCLAIMER: Information contained in this email or any attachment may be of a confidential nature which should not be disclosed to, copied or used by anyone other than the addressee. It may also be legally privileged. If you receive this email in error, please delete the email from your computer and notify the sender immediately by return E-mail. Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium. Virus Warning: _ This email has been scanned for all viruses by Claranet Mail Scanner, powered by MessageLabs. For more information on a proactive email security service working around the clock, around the globe, visit http://www.uk.clara.net _ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
[fossil-users] Postmortum: DRH in Munich
Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what ideas others can derive from the descriptions above. i unfortunately failed to take any pictures except one of the whiteboard. :/ We would love to hear your thoughts/elaborations on the above ideas. Happy Hacking! PS: Please pardon my brevity and typing mistakes - i'm on a tablet. ___ 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] Stash with renames
On Tue, Jul 3, 2012 at 12:20 PM, Lluís Batlle i Rossell vi...@viric.namewrote: Maybe 'fossil stash' should handle better the renames situation? It looks a bit broken. A stashed item is a snapshot of its state in the past, and that state is constant/final/immutable (as the past always is in fossil). A rename happens in the future, and a stash cannot be aware of that (nor even know if it should, for a given case, handle that - in the generic case this is not answerable). Perhaps stash is doing abstract the equivalent of fossil revert when it should instead be doing fossil revert stashedfile1... stashedfileN? i'm taking a look at it now, but the stash apply code is new to me and does manifest-level work i'm not familiar with :/. i'm not certain if i'll have this grokked in my last remaining hacking hour for the day :(. (i did, however, see an easy optimization opportunity to skip an unnecessary blob_compare() in one branch, and that will be checked in soon.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 9:43 PM, Stephan Beal sgb...@googlemail.com wrote: Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Multiple levels of undo also came up. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Stash with renames
On Tue, Jul 3, 2012 at 12:20 PM, Lluís Batlle i Rossell vi...@viric.namewrote: here 'fossil stash' behaved weird, if I had done 'fossil mv' operations. The renames remain in the 'fossil status' after stash, and it also caused a revert of all files in my repository; at elast that's what the console log said. Maybe 'fossil stash' should handle better the renames situation? It looks a bit broken. Sorry, did this happen on a save or apply/pop operation? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 3:43 PM, Stephan Beal sgb...@googlemail.com wrote: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) I thought the coolest idea was for having the ability to define new pages in the web interface, delivering repository-specific content. By repository specific, I mean content that is not synced using fossil sync (though perhaps it could be using fossil config pull or fossil config push). Each content page would define a new URL. The custom pages can be used to store things like prebuilt binaries - things you might want to include on a website but which do not want to version. Or it can be used to hold the initialization HTML page for a JSON-version of the web interface. In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what ideas others can derive from the descriptions above. i unfortunately failed to take any pictures except one of the whiteboard. :/ We would love to hear your thoughts/elaborations on the above ideas. Happy Hacking! PS: Please pardon my brevity and typing mistakes - i'm on a tablet. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] Merging with renames (new directories)
On Tue, Jul 3, 2012 at 2:49 PM, Lluís Batlle i Rossell vi...@viric.namewrote: Stracing, it shows it's a open(...,O_CREAT,...) call failing with ENOENT. Have you got the fossil function name which triggered that? open() is called somewhere deeper down than merge.c, and it's not obvious to me where that's being triggered. Was it perhaps merge.c:380 (vfile_to_disk())? My guess is that the bug is at vfile.c:311. We have a routine for creating dirs (file_mkdir()), but i don't see a recursive one (equivalent of mkdir -p). Before i add such a beast, do any of you know if we already have such a routine? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Merging with renames (new directories)
On Tue, Jul 3, 2012 at 3:07 PM, Bob Bellchambers-Wilson bob.wil...@bellfruitgames.co.uk wrote: Sorry guys, somehow outlook flipped messages on me while replying to a completely different email! Well, at least it wasn't a letter to your mistress ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 10:38 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Jul 3, 2012 at 3:43 PM, Stephan Beal sgb...@googlemail.comwrote: - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). Richard asked me to give him a list of pros and cons regarding jQuery, i.e. what would we gain by using it. It just occurred to me, though, that i have a web page dedicated to jQuery (admittedly dated because i no longer actively develop jQuery plugins, but i still use it in _all_ of my browser-side JS code). Here it is: http://wanderinghorse.net/computing/javascript/jquery/ And from long-gone days when i was active on the jQuery mailing list, an open letter to non-believers: http://wanderinghorse.net/computing/javascript/jquery/openletter-jquery.txt i still stand by that today :-D @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 3:58 PM, Stephan Beal sgb...@googlemail.com wrote: @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) Heh, well, that's because it doesn't make sense. The actual saying is: The proof of the pudding is in the eating. :) Bill ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 11:04 PM, Bill Burdick bill.burd...@gmail.comwrote: On Tue, Jul 3, 2012 at 3:58 PM, Stephan Beal sgb...@googlemail.comwrote: @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) Heh, well, that's because it doesn't make sense. The actual saying is: The proof of the pudding is in the eating. :) LOL! Well, it certainly tastes better than my foot ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 4:08 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 3, 2012 at 11:04 PM, Bill Burdick bill.burd...@gmail.comwrote: On Tue, Jul 3, 2012 at 3:58 PM, Stephan Beal sgb...@googlemail.comwrote: @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) Heh, well, that's because it doesn't make sense. The actual saying is: The proof of the pudding is in the eating. :) LOL! Well, it certainly tastes better than my foot ;). It's a very misquoted quotation. Like, money is the root of all kinds of evil, is usually quoted as, money is the root of all evil. It's just par for the course. Most people say, the proof is in the pudding, but, unlike you, they just don't realize that they just said something that doesn't really make very much sense. I mean, if the proof is in the pudding and you're making pudding, then the pudding doesn't exist yet. Maybe they should say, the proof will be in the pudding. Anyway -- I guess this is turning into a thread-jack :). Bill ___ 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] Postmortum: DRH in Munich
On 04/07/2012, at 5:43 AM, Bill Burdick wrote: On Tue, Jul 3, 2012 at 4:08 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 3, 2012 at 11:04 PM, Bill Burdick bill.burd...@gmail.com wrote: On Tue, Jul 3, 2012 at 3:58 PM, Stephan Beal sgb...@googlemail.com wrote: @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) Heh, well, that's because it doesn't make sense. The actual saying is: The proof of the pudding is in the eating. :) LOL! Well, it certainly tastes better than my foot ;). It's a very misquoted quotation. Like, money is the root of all kinds of evil, is usually quoted as, money is the root of all evil. Actually, the correct quote is For the love of money is a root of all kinds of evil. - http://www.biblegateway.com/passage/?search=1+Timothy+6%3A10version=NIV It's just par for the course. Most people say, the proof is in the pudding, but, unlike you, they just don't realize that they just said something that doesn't really make very much sense. I mean, if the proof is in the pudding and you're making pudding, then the pudding doesn't exist yet. Maybe they should say, the proof will be in the pudding. Anyway -- I guess this is turning into a thread-jack :). Ditto Steve ___ 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] Postmortum: DRH in Munich
On Tue, Jul 3, 2012 at 9:42 PM, Steve Landers st...@digitalsmarties.comwrote: On 04/07/2012, at 5:43 AM, Bill Burdick wrote: On Tue, Jul 3, 2012 at 4:08 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 3, 2012 at 11:04 PM, Bill Burdick bill.burd...@gmail.com wrote: On Tue, Jul 3, 2012 at 3:58 PM, Stephan Beal sgb...@googlemail.com wrote: @DRH: the proof is in the pudding (though i've never really understood where that phrase comes from) Heh, well, that's because it doesn't make sense. The actual saying is: The proof of the pudding is in the eating. :) LOL! Well, it certainly tastes better than my foot ;). It's a very misquoted quotation. Like, money is the root of all kinds of evil, is usually quoted as, money is the root of all evil. Actually, the correct quote is For the love of money is a root of all kinds of evil. - http://www.biblegateway.com/passage/?search=1+Timothy+6%3A10version=NIV It's just par for the course. Most people say, the proof is in the pudding, but, unlike you, they just don't realize that they just said something that doesn't really make very much sense. I mean, if the proof is in the pudding and you're making pudding, then the pudding doesn't exist yet. Maybe they should say, the proof will be in the pudding. Anyway -- I guess this is turning into a thread-jack :). Ditto My bad -- I was speaking off the top of my head. Bill ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
