Re: [fossil-users] Nested check-outs
On Nov 17, 2011, at 2:04 AM, Gareth Roberts wrote: Hi Will, fossil open --nested allows opening a fossil within an existing checkout. This question came up earlier this week as well; it may be worth looking at the archives. Solutions included fossil open --nested and scripting a checkout of external dependencies. Thanks, Gareth. I knew I'd seen something, but I couldn't remember enough about what it was to even go looking for it. If I understand it correctly from the previous posts to the list, using fossil open --nested just allows a nested checkout to live within a parent checkout without confusing fossil; but the two checkouts are essentially separate. In other words, it's like a Subversion svn:external, except that fossil doesn't check it out for you automatically; you have to do that yourself (i.e., by make getmydependencies or something like that). Thanks! Cheers, Gareth On Thu, 17 Nov 2011 04:38:49 -, Will Duquette w...@wjduquette.com wrote: Howdy! Is there a document that describes the best practices for a project that involves components from multiple fossil repositories? For example, suppose I've got an infrastructure library that is in its own fossil repository. And I've got an application that uses that infrastructure library. With Subversion, I'd do an svn:external to pull the infrastructure library into my working area as a subdirectory. Is there an equivalent way to do this with fossil that won't get me into trouble? Thanks very much! Will Mr. Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Mr. Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Nested check-outs
Howdy! Is there a document that describes the best practices for a project that involves components from multiple fossil repositories? For example, suppose I've got an infrastructure library that is in its own fossil repository. And I've got an application that uses that infrastructure library. With Subversion, I'd do an svn:external to pull the infrastructure library into my working area as a subdirectory. Is there an equivalent way to do this with fossil that won't get me into trouble? Thanks very much! Will Mr. Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog ___ 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 do people create branches as a separate step? Was: Unable to sign manifest
On Aug 9, 2011, at 7:58 AM, Richard Hipp wrote: Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation. I'd tend to do this so that I don't forget to add -branch new-branch when I commit. If I'm using a different branch, it's because the development context has changed; I want the state of my work area to match the development context. If I start editing files while planning to fossil commit -branch new-branch, then my work area doesn't match my development context. If I create the new branch explicitly, then I've changed my development context in my head AND in my work area. Will Mr. Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog ___ 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] Integration into Emacs Version Control
Venkat, I came in late on this thread...is your version of vc available somewhere? Thanks! Will Duquette On May 5, 2010, at 9:16 PM, Venkat Iyer wrote: From: Gour g...@gour-nitai.com I'm still in the evaluating phase for Fossil, but being an Emacs user, I'm curious why you're integrating into VC and not DVC? (http://www.xsteve.at/prg/emacs_dvc/dvc.html) Two answers. 1. I had to make it as painless as possible for my users (who unfortunately are more used to traditional VCS). I'm currently tracking fossil head with minor changes to 2 files, so it's been a relatively successful project for me. 2. I had never heard of dvc. I'm sure I can make it work with fossil. But if the user experience is much different, then I'm not helping my users. I really didn't have a choice. I wanted fossil, my users absolutely needed it to work with emacs vc. Would you recommend DVC over VC? Why? - Venkat ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] Integration into Emacs Version Control
Thanks! Sent from my iPhone On May 6, 2010, at 8:25 AM, Gour g...@gour-nitai.com wrote: On Thu, 6 May 2010 07:04:10 -0700 Will == Will Duquette wrote: Will I came in late on this thread...is your version of vc available Will somewhere? See attachment in: http://article.gmane.org/gmane.comp.version-control.fossil-scm.user/1300 Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ___ 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] tree checksum does not match
On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) Will -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
I was unclear, apparently. Suppose fossil rm *.foo deletes the files from the file system and from Fossil. If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Then, I can do fossil rm *.foo Note that I'd expect fossil rm *.foo only to remove files from the file system that it can remove from the repository, i.e., if I had an extra file, not_added.foo, I'd expect fossil rm *.foo to live it alone. Will On Dec 10, 2009, at 3:20 AM, Benjohn Barnes wrote: On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org wrote: Which is exactly why fossil rm *.foo should delete *.foo from the file system as well as from the repository. If you forget, and do rm *.foo, then you can ask fossil to give you the files back, and then do fossil rm *.foo so that you don't need to type in all of the names. Will Although, I think, as you don't have any globbing, when you ask fossil to give you the files back, you do need to type in all the names :-) (unless those deletions are the only changes that you've made to the working copy). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
On Dec 10, 2009, at 6:39 AM, Jeremy Cowgar wrote: Will Duquette w...@wjduquette.com wrote: I was unclear, apparently. Suppose fossil rm *.foo deletes the files from the file system and from Fossil. If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Then, I can do fossil rm *.foo Note that I'd expect fossil rm *.foo only to remove files from the file system that it can remove from the repository, i.e., if I had an extra file, not_added.foo, I'd expect fossil rm *.foo to live it alone. What's wrong with that? I would expect that to be good behavior? Nothing's wrong with that; everything's right with that. :-) This is apparently my week for being unclear. In case I'm still unclear, I'm very much in favor of fossil rm working in the way described above. Will Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
On Dec 10, 2009, at 7:30 AM, Ramon Ribó wrote: If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Are you sure that this command is going to give that files back? Have you tried it? This is another field where there are currently proposals to change current behavior and do what you think that it does. The principle of least surprise is not followed here. This is a proposal for how I think fossil rm should work. It's consistent with how svn rm works. At present it's not what happens. Will 2009/12/10 Will Duquette w...@wjduquette.com: I was unclear, apparently. Suppose fossil rm *.foo deletes the files from the file system and from Fossil. If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Then, I can do fossil rm *.foo Note that I'd expect fossil rm *.foo only to remove files from the file system that it can remove from the repository, i.e., if I had an extra file, not_added.foo, I'd expect fossil rm *.foo to live it alone. Will On Dec 10, 2009, at 3:20 AM, Benjohn Barnes wrote: On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org wrote: Which is exactly why fossil rm *.foo should delete *.foo from the file system as well as from the repository. If you forget, and do rm *.foo, then you can ask fossil to give you the files back, and then do fossil rm *.foo so that you don't need to type in all of the names. Will Although, I think, as you don't have any globbing, when you ask fossil to give you the files back, you do need to type in all the names :-) (unless those deletions are the only changes that you've made to the working copy). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
On Dec 9, 2009, at 11:39 AM, Stephan Beal wrote: IMO, duplicating the shell functionality is the wrong approach, mainly because there will be behavioural differences between fossil's and the shell's globbing. i agree it would be convenient for us users, but it technically could not be guaranteed to behave the same as the user's shell, and therefore could cause confusion or even data loss (e.g. accidental removal or even purging by using an incompatible glob pattern). Which is exactly why fossil rm *.foo should delete *.foo from the file system as well as from the repository. If you forget, and do rm *.foo, then you can ask fossil to give you the files back, and then do fossil rm *.foo so that you don't need to type in all of the names. Will -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] Commit failing... retyping commit message
On Dec 9, 2009, at 11:41 AM, Stephan Beal wrote: On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote: It seems that fossil is in need of two things: 1. Save the commit message to a file when the commit failed 2. Provide a means of making fossil read the commit message from a file If you're having to re-*type* your commit message, you're using the wrong shell. All modern shells support up-arrow to scroll back through your command history. If you're in the Bash shell, try tapping Ctrl-R, then tap -m (the commit message argument), and the history will jump back to the most recent command with -m in it. Then just tap enter. Unless you like to type long commit messages, and so do not use the -m option. -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] Commit failing... retyping commit message
On Dec 9, 2009, at 1:29 PM, D. Richard Hipp wrote: On Dec 9, 2009, at 12:39 PM, Jeremy Cowgar wrote: In the 3 features... thread, I read from Michael: Secondly, I always get bit with my commit failing and then having to type in my comment again (after the monkeying around with 'fossil rm'). It seems that fossil is in need of two things: 1. Save the commit message to a file when the commit failed 2. Provide a means of making fossil read the commit message from a file It seems to me that a better approach would be to improve the commit command so that it does a better job of detecting problems *before* it asks you to type in the commit message. In other words, if the commit is going to fail, have it fail early. What is it that is causing your commits to fail so frequently? What can we do to get fossil to detect these problems before you type in your commit message? What's bitten me a time or two is saying fossil commit, seeing the list of files, and then saying, Oh, rats, I forgot to do a fossil add, or I forgot to update a doc file. So I do it; and then fossil tells me that the checksum has changed (or something like that) and doesn't commit. This case comes up often enough that it would be nice if fossil allowed it to work, possibly with a confirmation from the user. -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] RSS feed times off?
Fossil does RSS? Cool! I did not know that. Will On Dec 8, 2009, at 9:31 AM, Jeremy Cowgar wrote: You can look at: http://jeremy.cowgar.com/mailroom/index.cgi/ timeline and see: 2009-12-08 17:20:15 * [d2dfbefa0e] Leaf Modified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging. (user: jnc, tags: trunk) 17:10:24 * Changes to wiki page mailroom (user: jnc) Now, looking at the RSS feed, I see: item titleModified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging./title pubDateTue, 8 Dec 2009 21:20:15 GMT/pubDate /item item titleChanges to wiki page [mailroom]/title pubDateTue, 8 Dec 2009 22:10:24 GMT/pubDate /item I snipped out some long elements, the important ones are of course the date and title so you can see the difference. The RSS feed URL is: http://jeremy.cowgar.com/mailroom/index.cgi/timeline.rss I have not dove into the time conversion side of fossil yet. Any one have a quick idea about the problem? Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] user(), cgi(), wiki() report functions
Brian,
I click on one of your links, and found myself at your fossil repo,
logged in as
btheado with full access to the Admin settings. Eeek!
Will
On Dec 8, 2009, at 8:51 PM, Brian Theado wrote:
I have ported the user() and cgi() sql functions from cvstrac to
fossil.
Also, I implemented functionality similar to cvstrac's wiki()
function.
I described what I did in a comment on this ticket:
http://fossil-scm.org/index.html/info/66de526498.
I have deployed a clone of the fossil repo containing my changes. See
the branch with my changes at
http://tkoutline.sourceforge.net/cgi-bin/fossil/timeline?t=sql-func.
I am running my modified version of fossil and created sample reports
illustrating the cgi() and wiki functionality.
Report 6 shows a count of tickets grouped by ticket type. The count
column in this report are wiki formatted hyperlinks to report 5. The
hyperlinks contain an extra url parameter named 'type'. The value of
this url parameter is dynamically built from the sql results.
Clicking the link launches report 5 which uses the cgi() function to
grab the 'type' parameter and filter the report results based on the
value. Essentially this is drill-down functionality. Difficult for
me to describe, but see the reports in action:
http://tkoutline.sourceforge.net/cgi-bin/fossil/rptview?rn=6
The sql for report 6 is:
SELECT
type,
'[/rptview?rn=5type=' || type || '|' || count(type) || ']' as
_wiki_count
FROM ticket
WHERE status IN ('Open', 'Verified')
GROUP BY type
ORDER BY count(type) DESC
The wiki formatting is triggered by the special '_wiki_' prefix on the
column name.
The sql for report 5 has type=cgi('type', 'Feature_Request') in the
where clause.
Brian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills
___
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] Search WAS:The case for Markdown
Burning? Not precisely; but it certainly seems like something that should be there. Will On Nov 30, 2009, at 4:36 AM, Stephen De Gabrielle wrote: Hi, Does anyone else have a burning desire for a search facility to be added to Fossil? Cheers, Stephen On Mon, Nov 30, 2009 at 10:32 AM, Benjohn Barnes benj...@fysh.org wrote: I'm not going to bother stopping it, nor did I plan to. I was only showing you what the first 10m showed. Now? YES: 13 NO: 3 Any: 13 Markdown: 3 Creole: 1 Don't forget to add in the Apathetic or Not sures. I'm so unsure and apathetic, I don't remember which one I picked. I do know I firmly ticked Any should it be changed (I take this to include extensions to the current system, if that seems more appropriate). Cheers, B ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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 case for Markdown (yes, I rtfm)
My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. On Nov 29, 2009, at 6:49 AM, Jeremy Cowgar wrote: Not at all as Markdown, Creole or Textile all look great as plain text. Those without the plugin will simply not have glorified HTML markup but they will still be able to participate. However, I only mentioned this option as some think proper wiki formatting is too much work. My real suggestion would be for fossil to adopt 1 major format as the format to use. Those that wish to use verbose HTML can still do so. Those that wish to have a nice formatting language that's easy to maintain/type/read/understand can use the formatting engine. No one looses. I'm failing to see how such an addition is generating such a vocal attack by a few. It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format making assumptions as to what will happen. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 9:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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 case for Markdown (yes, I rtfm)
Fair enough. On Nov 29, 2009, at 8:01 AM, Jeremy Cowgar wrote: I think you are misunderstanding what one should document in the fossil wiki. Not at all end user documentation. The documentation I put there is design documentation, application goals/requirements, etc... End user documentation is something totally different that is not at all contained in the Fossil wiki. For me, the Fossil wiki really isn't even of interest to non-developers (users) in any way. My public project page will be in some other format, most likely a CMS system with news, blog, forums, etc... Documentation will be in static HTML most likely that is then displayed in an HTML viewer of a GUI application or hosted on a website with hooks into a web application. The fossil wiki is for developers documenting the development process for me. That's what I use the Fossil wiki for. Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 10:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. On Nov 29, 2009, at 6:49 AM, Jeremy Cowgar wrote: Not at all as Markdown, Creole or Textile all look great as plain text. Those without the plugin will simply not have glorified HTML markup but they will still be able to participate. However, I only mentioned this option as some think proper wiki formatting is too much work. My real suggestion would be for fossil to adopt 1 major format as the format to use. Those that wish to use verbose HTML can still do so. Those that wish to have a nice formatting language that's easy to maintain/type/read/understand can use the formatting engine. No one looses. I'm failing to see how such an addition is generating such a vocal attack by a few. It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format making assumptions as to what will happen. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 9:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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] Zip files won't unzip on OS X
Anonymous can clone it, according to the Users page. I've not tried that myself. Will On Nov 29, 2009, at 5:04 PM, chi wrote: Will Duquette wrote: Chi, Hello Will, Thanks for the word about the bug fix. I'll see about updating to the latest Fossil binary; I'd been putting it off until there was some compelling reason. :-) I am lucky, that my answer was helpful :-) (...) Some of the Notebook infrastructure code is available at http://wjduquette.com/projects/glue.cgi , though, including a variant of the Notebook 2 markup and renderer. And that *is* in Fossil. Nice! :-) Is it allowed to clone that repository? Ciao, chi. (...) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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 case for Markdown (yes, I rtfm)
Purely out of curiousity, I've glanced at Markdown and Creole, neither of which I've used. The problem with Markdown is that the format as defined simply isn't a Wiki format. It's Wiki-like, but doesn't include the markup for links to wiki pages. (There's some kind of linking, but it isn't wiki- linking.) So if Markdown is used it will be necessary to extend it. There appear to be three C implementations of Markdown; one, which I didn't look at, is only a partial implementation. One, peg-markdown, is apparently profligate of memory use, but is intended to be easily extensible. Another, discount, has an API that (to my casual view) doesn't appear to be tailored for use in a Wiki; changes would be required. How easy it would be to extend, I dunno. Creole, on the other hand, *is* a Wiki syntax, though it's an odd one (**bold**? //italics//? where did *those* come from?) (Yes, I know that the Creole site has the rationale for everything.) However, the list of extant parsers on the Creole web page doesn't include one written in C. At a casual glance, then, neither Markdown nor Creole looks like an easy drop-in replacement for what we have now. (Feel free to prove me wrong; ten minutes of web-browsing doesn't make me any kind of expert.) Will On Nov 29, 2009, at 4:55 PM, Kurtis Rainbolt-Greene wrote: Just to be clear here since there has been some distracting arguments made: There is no bikeshedding being done in this thread. As proof of point a clear major majority do not care what color the bikeshed is (AKA, what format to use) according to my poll. I see two (major) sides of this conversation: 1. People who want better formatting, whatever the result. 2. People who are worried that everyone else is worried about the color of the bikeshed. The only minority are those who are happy with HTML. Since any markdown language allows HTML they really don't factor into this topic. tl;dr quit concern trolling On Sun, Nov 29, 2009 at 4:19 PM, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com/ ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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 case for Markdown (yes, I rtfm)
Some of the e-mails in this thread today made it sound like it would be an easy thing to just drop one of these formats in; or, at least, so I interpreted them. As someone noted, a little data is a useful thing, so I went and found some. Understand, I'm not advocating for any result in particular. On the one hand, I wouldn't object to a richer markup language; on the other, I don't really need it; and I don't much care what gets picked. By choice I'd prefer something similar to poortext, the markup used by my Notebook app, but it doesn't have a C implementation either, and nothing but Notebook uses it. Markdown looks fine so far as it goes (which isn't quite far enough); Creole looks weird; Wikipedia's markup is certainly functional, and widely used. Will On Nov 29, 2009, at 6:25 PM, Jeremy Cowgar wrote: I have not done extensive research either, however, I would say solve the first problem first. 1. Can we extend the wiki to allow better text formatting? 2. If so, what format would we want to implement? 3. Who will do the implementation? 4. --- Now we can look at libraries --- 4a. Is there a suitable library? How will it integrate? 4b. Do we need to develop our own? Can it be done reasonably in small stages, I.e. bold, italic, typewriter type in one stage. Later lists/ nested lists/numbered lists, Later tables, etc... I.e. does it have to be done all at once or can we slowly add to it as time permits. I think researching a library first is the wrong way to go about it. It may be that there is no suitable library, but does that then mean that the need doesn't exist? There may be a suitable library but the idea of a dependency scares everyone off so maybe we need a C source file that does the formatting and can be added too slowly, etc... Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 9:15 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) Purely out of curiousity, I've glanced at Markdown and Creole, neither of which I've used. The problem with Markdown is that the format as defined simply isn't a Wiki format. It's Wiki-like, but doesn't include the markup for links to wiki pages. (There's some kind of linking, but it isn't wiki- linking.) So if Markdown is used it will be necessary to extend it. There appear to be three C implementations of Markdown; one, which I didn't look at, is only a partial implementation. One, peg-markdown, is apparently profligate of memory use, but is intended to be easily extensible. Another, discount, has an API that (to my casual view) doesn't appear to be tailored for use in a Wiki; changes would be required. How easy it would be to extend, I dunno. Creole, on the other hand, *is* a Wiki syntax, though it's an odd one (**bold**? //italics//? where did *those* come from?) (Yes, I know that the Creole site has the rationale for everything.) However, the list of extant parsers on the Creole web page doesn't include one written in C. At a casual glance, then, neither Markdown nor Creole looks like an easy drop-in replacement for what we have now. (Feel free to prove me wrong; ten minutes of web-browsing doesn't make me any kind of expert.) Will On Nov 29, 2009, at 4:55 PM, Kurtis Rainbolt-Greene wrote: Just to be clear here since there has been some distracting arguments made: There is no bikeshedding being done in this thread. As proof of point a clear major majority do not care what color the bikeshed is (AKA, what format to use) according to my poll. I see two (major) sides of this conversation: 1. People who want better formatting, whatever the result. 2. People who are worried that everyone else is worried about the color of the bikeshed. The only minority are those who are happy with HTML. Since any markdown language allows HTML they really don't factor into this topic. tl;dr quit concern trolling On Sun, Nov 29, 2009 at 4:19 PM, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com
Re: [fossil-users] Zip files won't unzip on OS X
Chi, Thanks for the word about the bug fix. I'll see about updating to the latest Fossil binary; I'd been putting it off until there was some compelling reason. :-) Snit is at SourceForge as part of Tcllib. Notebook is in Subversion; and I'm not doing much with it at present. I'd based Notebook 3 on Tkhtml 3, which is no longer being developed (sigh!), and I haven't gotten up the gumption to do anything about that. Some of the Notebook infrastructure code is available at http://wjduquette.com/projects/glue.cgi , though, including a variant of the Notebook 2 markup and renderer. And that *is* in Fossil. Will On Nov 28, 2009, at 4:03 PM, chi wrote: Will Duquette wrote: - hide quoted text - Hello Will, I've got a fossil repository at http://wjduquette.com/projects/robbie.cgi. If I download a Zip Archive for a leaf, the OS X Archive Utility won't unzip it; it says that it's corrupted. The command-line unzip command unzips it just fine. jepp, this was an issue for Fossil for a longt time (ticket 923a912309). Fortunately this problem was solved with revision d78835d2ff -- commited 18-Oct-2009. Unfortunately you Fossil binary (revision 37f295c310) from 21-Sep-2009 is too old and therefore does not contain the fix. So if you upgrade your binary (and probably fossil rebuild the repository) the problem should vanish ... BTW: Does you also host your excellent Notebook and Snit with Fossil? (...) Best regards, chi ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] More info on ticket 1e919e389b
Richard, That's what it is. I unintentionally forked the repository, and the working directory in which fossil update was doing nothing was on a different leaf. fossil leaves -- I shall remember this command. Thanks very much! Will On Nov 28, 2009, at 3:31 PM, D. Richard Hipp wrote: On Nov 28, 2009, at 4:49 PM, Will Duquette wrote: Richard asked that I give more information on ticket 1e919e389b here on the mailing list. What I was seeing, and reported in that ticket, was this: * I was running on Ubuntu Karmic Koala. * I did a fossil all sync to sync a local repository with the one on my web server; I saw the delta and artifact numbers being received that I expected. * I went to my local work area and did a fossil update. It returned silently, when I knew it should not. Maybe you need to run fossil update trunk or fossil update --latest In other words, maybe your Karmic Koala checkout is sitting on the leaf of a branch whilst the rest of your project is progressing on a different branch. Can this happen by accident? Because I've not intentionally created any branches. What does fossil leaves tell you? Are you sitting on one of the leaves shown, and are you wanting to update to a different leaf? If so, you can always do: fossil update leave-version-number-prefix * I then did a fossil open in a new directory, and got the checkout I expected. * I then checked another project's repository and had the same experience with that one. * In both cases, fossil status indicated that I was up-to-date with the trunk. Richard then asked that I try a number of things: * What do you see if you strace in front of fossil update: * A whole lot of stuff, which I was at a loss to interpret. What should I be looking for? * What do you see if you use --sqltrace? * Again, a whole lot of stuff. What should I be looking for? I can attach it to an e-mail if you like. * Does fossil update work if you specify a specific version to check out? * YES, it does. * Have I tried running fossil in a debugger to see what is going on? * Nope. I'm not building it myself. * What commands actually work? * fossil sync works. * fossil ui works. * fossil status reports a different checkout UUID than the head and reports the same as fossil status. * fossil info reports the same. * fossil extras shows the files I'd expect. I think the overall sequence of events might have been something like this: * I have two laptops, A and B, and a web server. * I had made changes on A, and done a fossil commit. I suspect that these changes had NOT been synced with the repository on the web server. * I had made changes on B, and done a fossil commit followed by a fossil sync. These changes were to different files than the changes on A. * I then did a fossil sync on A. * And then fossil update in the working directories on A didn't update anything. Any ideas? Will Duquette -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil- users D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
