[fossil-users] Minor changes for Check-in Names page
Hello, A few minor suggestions for the Check-in Names wiki page (http://www.fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki): * Should it mention that prev is also accepted as a special name? * I think ckout doesn't work anymore and should be removed from the list. (See check-in [badb9ff231].) * Should it mention that some commands also accept latest as a special name? (Currently only update but one could argue that checkout should also, for consistency.) Thanks. Edward ___ 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 sqlite3
Od: Edward Berner e...@bernerfam.com Komu: fossil-users@lists.fossil-scm.org Datum: 31.12.2012 08:53 Předmět: Re: [fossil-users] fossil sqlite3 On 12/30/2012 10:43 PM, Michael Richter wrote: Is there any way to execute SQL statements from the command line using fossil sqlite3? The docs for this http://www.fossil-scm.org/xfer/help?cmd=sqlite3 are a bit skimpy (to say the least). Like what are the /?OPTIONS?/ mentioned, precisely? What I'm specifically trying to accomplish is to extract the project ID from the repository in a script file. If there's another way to do this I'm happy to use that instead, of course. I think fossil info will get what you're looking for. eg: $ ../fossil info -R ~/fossil/test.fossil project-name: unnamed project-code: 07660919180b651835b3a51776a58007ca9fb6f9 fossil info calls it project-code but it seems to be the same thing that fossil new and fossil clone call project-id. using fossil sqlite3: echo select value as 'project ID' from config where name = 'project-code'; statement.sql fossil sqlite3 -R .\myfossilclone.fossil .\statement.sql (myfossilclone.fossil is my clone of fossil repository) Peter ___ 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 vs. Git/Mercurial/etc.?
My understanding is that git rebase is used primarily to produce patches to be applied onto a particular tag or checkin of a destination repository, to give the same result as currently in the source repository, but without requiring the destination to do a git pull from the source repo, or to only pull a single prettified branch, rather than the history which made it happen. The source, however must have done a pull from the destination to get the start point of the patch. The essential feature is that the destination repo is somehow cleaner or of higher status or authority than the source repo. The source repo holds additional private content, perhaps including messy time-consuming development, and pulls at least certain content from the destination from time to time. When the source repo is finally ready to use, the messy development gets repackaged as a simple difference from the current state or some known recent state of the destination. I can't see what a rebase equivalent in fossil might do, which can't already be done using fossil diff (if you really want patches), or using private branches which get merged back into public ones from time to time, with only the public branches available to pull from. The fossil way of doing things (to my understanding) is to expose and preserve all history, while the whole idea of git rebase is to hide some of the history. If you really want rebase, you're probably looking in the wrong place, but I think you can already bend fossil to do it, without needing any changes to the tool itself. -- Christopher Vance ___ 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 sqlite3
On 31 December 2012 15:53, Edward Berner e...@bernerfam.com wrote: fossil info calls it project-code but it seems to be the same thing that fossil new and fossil clone call project-id. Waitwhat? My version of Fossil (This is fossil version 1.25 [558a17a686] 2012-12-22 13:48:31 UTC) doesn't show anything about project-id for fossil new/clone. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ 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 sqlite3
On 12/31/2012 12:24 AM, Michael Richter wrote: On 31 December 2012 15:53, Edward Berner e...@bernerfam.com mailto:e...@bernerfam.com wrote: fossil info calls it project-code but it seems to be the same thing that fossil new and fossil clone call project-id. Waitwhat? My version of Fossil (This is fossil version 1.25 [558a17a686] 2012-12-22 13:48:31 UTC) doesn't show anything about project-id for fossil new/clone. What do you get when you create a test repository? It should, I think, display the project-id, etc., after creating the repository. eg: $ ./fossil new test.fossil project-id: 2d7cade36dce2af94df648e178d588e5a3b00a14 server-id: af94c0a2462bc18103a19c20fd0b3918c3f9a2a3 admin-user: erb (initial password is 811b05) -- Edward ___ 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 vs. Git/Mercurial/etc.?
[Sorry to break threading, but I unsubscribed, then saw this in the archives and re-subscribed just to answer, but I don't have the Message-ID.] On Sun, Dec 30, 2012, Joerg Sonnenberger wrote: On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote: I repeat: git rebase does not manipulate the pre-existing tree, it does not destroy any history already in the tree. The only destructive action that git rebase does is change the commit that a branch _name_ points to, and from a fossil philosophy perspective this is the only aspect of git rebase that is worth differing on. git rebase is destructive due to a combination of not supporting more than one leave revision for a given named tag and dropping all other revisions on a non-fastforward push. Now a combination of recording what a rebase is based on and just marking the original commit as closed would pretty much serve the purpose of fossil. I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). Also, I'd like to be able to ask about previous rebasings of a given branch and be able to name them, something like branchname%N, where N is the Nth previous rebasing. This way I could checkout, diff, ... old versions of a branch. And then there'd be no need to create a copy of the victim branch prior to rebasing. This alternative to my first proposal strikes me as particularly useful. Thank you for mentioning it. Nico -- ___ 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 sqlite3
On 31 December 2012 17:27, Edward Berner e...@bernerfam.com wrote: Waitwhat? My version of Fossil (This is fossil version 1.25 [558a17a686] 2012-12-22 13:48:31 UTC) doesn't show anything about project-id for fossil new/clone. What do you get when you create a test repository? It should, I think, display the project-id, etc., after creating the repository. eg: $ ./fossil new test.fossil project-id: 2d7cade36dce2af94df648e178d588**e5a3b00a14 server-id: af94c0a2462bc18103a19c20fd0b39**18c3f9a2a3 admin-user: erb (initial password is 811b05) Ah. I misunderstood. I thought you meant there was a command line option related to the project ID. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ 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 vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 9:41 PM, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: Go back through those 30 posts you mentioned. Go back to the very first one from me. I tried to be concise and wrote just three paragraphs that, IMO, captured what was needed. I certainly did not say I want git rebase in fossil and then watched the fireworks -- no, I explained *concisely* (or at least that was my aim). No, you said I want something slightly different than git rebase in fossil. Concise? Yes. Precise? No. Well-defined? No. Useful? No. I unsubscribed. I resubscribed to answer Joerg's very useful comment, and to address your insinuation that I've been trolling: If I had written a ten-page post explaining in excruciating detail [...] That depends on the goal. If you want to troll the list, then arguing for rebase is a good choice. If you want fossil to incorporate a solution for your problem, you should provide the information people are asking for. Given how poorly your attempt to work with the comunity has gone, giving up now isn't an unreasonable option. On the other hand, if you want to be able to use fossil, and are willing to work with us to solve your problem instead of arguing about what rebase does, you can start by answering our questions. I was going to let you have the last word, and, indeed, I will since I will re-unsubscribe shortly. But I feel I must at least address this insinuation that I was trolling. I think any reasonable human being reviewing this thread will conclude that I've been sincere. I've explained in detail, and I've answered the questions that have been raised, such as here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html and here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html I think those two posts in particular are quite detailed and informative. Nor did I know that bringing up rebase would arouse fury. I knew it was controversial, but not that it was anathema, and I thought I could make an argument for a variant of rebase that should fit within the fossil philosophy (and I still think so; e pur si muove). Thus my wading in here could not be considered trolling. If I were to not give up I might be trolling, but trust me, I give up (unless we hear from the project's principals anything supportive, or if they ask questions that I should answer). Trust me, I feel awful about filling unknown subscribers inboxes with my responses on this thread, and the responses those have elicited. I have found your responses to me to be hostile, and downright silly. I've also briefly reviewed the rm/mv thread and I find similar silliness there by various members of the community. I am frustrated, and I acknowledge that I've am having trouble hiding my frustration. But I do think that you have shown an utter lack of hospitality and open-mindedness. This is why I will now abandon Fossil, even though there are many ways in which I think Fossil is superior to the competition -- your hostility turns me off. For instance, you haven't answered any of my questions. You've explained in detail what rebase does, but that's irrelevant, because rebase is only an approximation to what you want, and you haven't explained how what you want is different in sufficient detail for us to figure out what that is. You haven't shown us why the existing solutions are to much work. You haven't said what kind of interface you want (otherr than interactive rebase, and you haven't said what that interface looks like!). You may think you have, but your opinion here doesn't matter: if we don't have a clear understanding of what you want, we don't have it, and the onus is on you to provide it. The best way to do that is by answering our questions. These two posts: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html answer your questions and explain in detail what I need to be able to do and why. Perhaps you missed them. You did respond once with this: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10602.html but you failed at reading comprehension, and by then I was ready to give up. But let me answer the one question you raise there: | I thought I did, but then you said rebase works on one branch. | | Except... | | So, if we have a branch called trunk with this history: | A---B---C---D | and a branch called new-feature with these commits | | Uh, that's *two* branches! What happened to rebase working on one branch? *git* rebase destructively affects ONE branch by making that one branch name point to a new line of commits that are not fast-forwards from the previous commit pointed to by that branch name. The rebase operation does additionally involve (read-only) an old base and new base commits. So, yes, rebase works on one branch. Rebase as a general
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On 31 December 2012 04:41, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: Go back through those 30 posts you mentioned. Go back to the very first one from me. I tried to be concise and wrote just three paragraphs that, IMO, captured what was needed. I certainly did not say I want git rebase in fossil and then watched the fireworks -- no, I explained *concisely* (or at least that was my aim). No, you said I want something slightly different than git rebase in fossil. Concise? Yes. Precise? No. Well-defined? No. Useful? No. If I had written a ten-page post explaining in excruciating detail what rebase is, why it matters, and how to adapt it to the Fossil philosophy, who -but who!- would have read that first post? I was being (I thought!) considerate. And judging by last night's 30 posts, would it have made any difference to post a thesis-length argument for rebase? And if so, how was I to know that? Or should I have given up at the very first sign of trouble? That depends on the goal. If you want to troll the list, then arguing for rebase is a good choice. If you want fossil to incorporate a solution for your problem, you should provide the information people are asking for. Given how poorly your attempt to work with the comunity has gone, giving up now isn't an unreasonable option. On the other hand, if you want to be able to use fossil, and are willing to work with us to solve your problem instead of arguing about what rebase does, you can start by answering our questions. For instance, you haven't answered any of my questions. You've explained in detail what rebase does, but that's irrelevant, because rebase is only an approximation to what you want, and you haven't explained how what you want is different in sufficient detail for us to figure out what that is. You haven't shown us why the existing solutions are to much work. You haven't said what kind of interface you want (otherr than interactive rebase, and you haven't said what that interface looks like!). You may think you have, but your opinion here doesn't matter: if we don't have a clear understanding of what you want, we don't have it, and the onus is on you to provide it. The best way to do that is by answering our questions. Rebase is a mass cherry-pick script, basically. You have an upstream trunk U and you branch B and in the simplest form rebase cherry-picks every single commint in B from the branching point to the tip one by one on top of U and marks the result as B. As has been pointed out this marking the result as B is the only destructive part which loses the original B and is unnecessary. Now the more involved version allows you to control how commits are picked. rebase presents you with a rebase recipe which shows the list of commits in B and all are marked with the default 'pick' which results with the above basic behaviour. You can edit the recipe to drop some commits, change the order in which they are picked, mark some for editing so rebase stops on them, mark some for squashing so rebase folds them into the previous commit. You can even select if the commit message of the squashed commit is appended or dropped but to edit the resulting message you have to run rebase again and mark for edit. Git add comes with a tool which allows you to pick only some files or some hunks from the checkout when creating a commit. It just shows the changed files and the hunks in the picked files one by one and asks you which to add. Sadly this tool is quite poorly integrated in git. When cherry-picking this cannot be used. To actually split a commit during rebase you have to mark the commit for editing, undo it, and then add parts of that commit as multiple commits possibly using the interactive add tool. When the commit adds files this is very error-prone. You can see that these tools are not available in fossil and with its web interface they could be presented in more friendly way than what the git commandline tools present. You can also see that while git has them they are not quite stellar. Thanks Michal ___ 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 vs. Git/Mercurial/etc.?
On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. -- Kind regards, Jan Danielsson ___ 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 sqlite3
there might have been email overlap. fossil info also spits out the project-id. That's what Petr was saying I believe. Date: Mon, 31 Dec 2012 17:51:31 +0800 From: ttmrich...@gmail.com To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] fossil sqlite3 On 31 December 2012 17:27, Edward Berner e...@bernerfam.com wrote: Waitwhat? My version of Fossil (This is fossil version 1.25 [558a17a686] 2012-12-22 13:48:31 UTC) doesn't show anything about project-id for fossil new/clone. What do you get when you create a test repository? It should, I think, display the project-id, etc., after creating the repository. eg: $ ./fossil new test.fossil project-id: 2d7cade36dce2af94df648e178d588e5a3b00a14 server-id: af94c0a2462bc18103a19c20fd0b3918c3f9a2a3 admin-user: erb (initial password is 811b05) Ah. I misunderstood. I thought you meant there was a command line option related to the project ID. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ 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 vs. Git/Mercurial/etc.?
On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. ___ 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 vs. Git/Mercurial/etc.?
On Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka yo...@q7.com wrote: On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. I haven't yet re-unsubscribed. Joerg's note added hope that more participants might add something of value. And your and Jan's note provide much appreciated relief: I'm not alone in finding Mike's hostility needs calling out. Thanks! Nico -- ___ 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 vs. Git/Mercurial/etc.?
I too have been saddened by the two flame wars on this list lately. I have held onto the list because Fossil is super valuable to me and I want to stay in the loop. I can only hope that folks will learn to think before hitting reply in the new year... michael at barrow dot me +1.408.782.4249 -Original Message- From: Steve Havelka Sent: 12/31/2012 10:01 To: Fossil SCM user's discussion Subject: Re: [fossil-users] Fossil vs. Git/Mercurial/etc.? On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. ___ 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 vs. Git/Mercurial/etc.?
On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote: I haven't yet re-unsubscribed. Joerg's note added hope Thank you for explaining rebase. It's not something I've ever needed to do, so I was skeptical of its value, and even more skeptical that it would ever be adopted by Fossil. While you have not converted me to an advocate, I've learned why you find it useful, and how it may be achieved without destroying history. I thank you for that, and for trying to be constructive and civil on this mailing list. e ___ 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 vs. Git/Mercurial/etc.?
On 12/31/12 19:52, Doug Currie wrote: On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote: I haven't yet re-unsubscribed. Joerg's note added hope Thank you for explaining rebase. It's not something I've ever needed to do, so I was skeptical of its value, and even more skeptical that it would ever be adopted by Fossil. While you have not converted me to an advocate, I've learned why you find it useful, and how it may be achieved without destroying history. I thank you for that, and for trying to be constructive and civil on this mailing list. I wholeheartedly agree (with the entire paragraph). I have never used rebase, nor do I see any use for it in my daily work-flow. That being said, I've thought that about many things in the past until it was suddenly available to me. (And history is full of such examples for others as well. (3D acceleration? Linux users used to be quick to point out that only 1ame g4m3rz and n00bs need it [because it wasn't available on Linux]. Nowadays some Linux desktops even require 3D acceleration to run normally)). But more importantly, I don't see my current own personal lack of interest for rebase as a barrier to having the feature in fossil. As long as it doesn't break the DAG I'm fine (and Nico was clear about that being the intention). Things makes fossil more appealing and could help transition users to it from other systems is good in my book. Nico and Joerg have made it clear to me, as a rebase n00b, that there's a very fossil way to have rebase. And if I read Michal Suchanek correctly, we could even do it better than the arch-typical example of rebase (git). ..and I hope Nico's constructive and civil tone will be an inspiration to the community going forward. -- Kind regards, Jan Danielsson ___ 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 vs. Git/Mercurial/etc.?
I concur, the last month has seen a breakdown in the normally friendly exchanges. Might I suggest that we look on tomorrow as a new beginning - after all, we all survived the end of the Mayan calendar :-) This is open source software - so no one owes anyone any support. If you want changes then actions speak louder than words, contribute a patch - even if its not accepted it shows a level of commitment and understanding of the code base. If you can't write code, then for goodness sake don't approach those that can/do with anything that could be construed as an expectation of paid levels of support. For those that do write the code, not every new idea is bad. Building a community means taking the long view. Everyone, please remember; a piece of software is not the mother of your children, it doesn't need to be defended at all costs. richard. On Dec 31, 2012, at 10:34 AM, Michael L. Barrow mich...@barrow.me wrote: I too have been saddened by the two flame wars on this list lately. I have held onto the list because Fossil is super valuable to me and I want to stay in the loop. I can only hope that folks will learn to think before hitting reply in the new year... michael at barrow dot me +1.408.782.4249 ___ 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 vs. Git/Mercurial/etc.?
On Mon, Dec 31, 2012 at 8:21 AM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/31/12 11:17, Nico Williams wrote: But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. At this point, I'd like to apologize the readers of the list, including Nico. My intent was not to be hostile or insulting. I was trying to get a description of the functionality he was looking for in terms of fossil's existing commands to be sure I correctly understood what he was suggesting. I got frustrated when he repeatedly ignored the question, and then outright refused to answer it, and clearly stepped over a line. Again, my apologies to all concerned. mike ___ 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 vs. Git/Mercurial/etc.?
Thanks Mike, I appreciate this. BTW, I now have a pretty good idea of what fossil rebase would look like; the discussion was a success, largely thanks to Joerg's insight. I've also started looking at src/merge.c to have an idea of how to implement a version of fossil merge --cherrypick that doesn't commit the merged changes (this being necessary to implement the interactive rebase edit-a-commit option, as well as for squashing) -- this is the essential ingredient, after all, and it seems like all that has to happen is we need an option to not update any non-temp tables in merge_cmd(). I think that will be a trivial change, actually, as it'd be a small modification to the fossil merge --nochange logic. I'll stop here. In six months I may have time to actually implement, and in the meantime I'll sketch an implementation. Happy New Year! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
