Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
2015-08-30 10:27 GMT+02:00 Stephan Beal : > On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin > wrote: >> >> Number #1 is the inhability to run "external" hooks easily, like >> execute this script each time a sync is done, for before checking in, >> run this scripts. (personnally I can live with that) > > > Management summary: that's primarily because (A) it's difficult to do > portably in a small package like Fossil and (B) because it opens up many > more potential failure cases than currently exist. (e.g. what happens to a > commit if an http connection to an external server, used by a trigger, > cannot be established?) Many hosting environments do not allow hosted > scripts/apps to establish outbound connections with external servers, which > inherently castrates such features, as well as your next one... > > That said, Fossil does have basic hooks support in the form of TH1/TCL > scripts, but i've never used them. Jan or Joe can certainly say more about > them. > Well last I tried there were not really useful and as for example in case of post bug report because of them being run with reporters (whcih makes sense given how they are designed) they were limited deeply limited in what they could do... I end it up back in the time at making them just to a http call to a local cgi which will then run a bunch complex fossil cli command to be able to grab the information I need (and send mails) it was in the end so complicated I gave up and switched the repo to github back in the time :( >> >> Number #3 can be related soehow to number #1 is the inability of the >> bug tracker to send mails. > > > Right - very closely related. Speaking to diverse mail servers reliably is > difficult to implement, and really needs an external mail API provider. > There is no _portable_ external provider API for sending mails. Doing so on > Unix, via sendmail, is simple enough, but fossil aims to provide all of its > features on all of its platforms, insofar as possible. (AFAIK, symlinks is > the only feature which doesn't achieve this ideal.) IMO this is the right > approach - limit fossil to features which are only available on all of its > platforms (AFAIK i'm one of the few here who believes, for that reason, that > fossil should not support symlinks). > >> >> Well my experience is quite the opposite. Most if not all projects I >> have been working relies on multi line logs. On some of them like all >> FreeBSD's repositories (svn and git) I cannot even imagine getting >> though history without multi time view. > > > My point was not so much about the multiline support, but the lack (in my > experience) of need for book-length commit messages. Without those, the lack > of multi-line support is moot. > >> Maybe that could be done via a new "log" which will be a kind of alias >> for fossil timeline -t ci ? (seriously when you come from other VCS >> the fossil timeline is disturbing :D) > > > Personally, i've always been against Fossil doing _any_ sort of manipulation > of commit message storage or display (e.g. word-wrapping in the console), as > it adds a disproportionate amount of complexity. If someone can read > programming code, they can certainly read commit messages, regardless of > their formatting. But i am likely in the minority on that point. > I 100% agree with you here, if fossil was not manipulating the message on display the multiline formatting would work out of box (they are correctly stored) Bapt ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
2015-08-30 4:35 GMT+02:00 Stephan Beal : > On Sun, Aug 30, 2015 at 4:27 AM, Warren Young wrote: >> >> On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin >> wrote: >> > >> > the number 2 major complaints I heard from user >> >> Really? What’s #1 and #3? :) > > > +1 > Number #1 is the inhability to run "external" hooks easily, like execute this script each time a sync is done, for before checking in, run this scripts. (personnally I can live with that) Number #3 can be related soehow to number #1 is the inability of the bug tracker to send mails. Which makes the casual reporter never reply to comments on their bug reports. Making interraction quite complicated with them. (This one is a huge pain for me and made me switch some of projects to github when they became popular :() While I'm here Number #4 is the inhability to have a equivalent of git am (getting a preformatted checkin which one can directly add on a repository to preserve the author of the checki) Personnally I do not feel that is it that important, it is simply sugar IMHO. > In some 20 years (as of this coming winter) of using source control (RCS => > CVS => SVN => Fossil), i can count on one hand the number of times i've seen > commit messages (in project i work on/contribute to) which span more than > two sentences. (Anything needing a longer explanation simply gets a ticket > number as the commit message.) i can count on 0 fingers the number of times > i have written a formatted-for-management commit message. > Well my experience is quite the opposite. Most if not all projects I have been working relies on multi line logs. On some of them like all FreeBSD's repositories (svn and git) I cannot even imagine getting though history without multi time view. If something is able to do multi-line formatting by default it works fine with one liners project, but something only able to format one line is broken for multi-line cases :( Maybe that could be done via a new "log" which will be a kind of alias for fossil timeline -t ci ? (seriously when you come from other VCS the fossil timeline is disturbing :D) Best regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Multi line formatting
Hi, Something which is really strange about fossil and is probably the number 2 major complaints I heard from user to whom I presented fossil, is the fact that by default fossil completly ignores the formatting of the commit logs. I do think that presenting the log mesages with proper formatting is important and improves a lot clarity. I sent long ago a couple of patches which have been integrated and greatly improved by fossil developers (thanks!) but the default remain on the non proper formatting without any simple mechanism to change that default. for the Web UI one can easily modify the CSS so it is not a big issue, however on the cli we have to use the non documend fmtflags (or something like that) with cryptic values :( Any plan to improved this? at least add a setting where we can define globally the format of the output? maybe switch by default to respect the formatting of the log? (fossil is the only vcs I know that is not respecting the formatting of the logs). Bapt ___ 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 XML SVN like export
2015-03-15 11:37 GMT+01:00 Kai Lauterbach : > Hi, > > is there away to export fossil's timeline like the log output in subversion? > > SVN export example: > > svn log -r 1:HEAD --xml --verbose --quiet > > if you have the json option enabled you do have: fossil json timeline checkin regards, Bapt ___ 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 source download naming scheme
2015-02-24 15:30 GMT+01:00 Richard Hipp : > On 2/24/15, robotanarchy wrote: >> Hello Fossil developers, >> >> I was building the fossil binary yesterday and I've noticed that the >> names of the tarballs aren't very userfriendly. >> >> As I see it, there are two tarballs that one could use, one is from the >> downloads page [1] and one is by using some strange SHA1 hash of the >> release, as in the Arch Linux package [3]. >> >> When downloading file [1], you'll get an archive that has a different >> file name than the included folder. The folder has different numbers >> at the end: >> >> fossil-src-201502231627 > > That's the date: 2015-02-23 16:27 > Along the time it has changed a couple of time: until (included): 20110101030647 it was MMDDhhmm for both the tarbal and the directory inside then it became MMMDDhhmmss for both the tarbal and the directory inside and with the last one it is MMMDDhhmmss for the tarbal and MMDDhhmm for the directory inside. The last version is the less convenient for a package maintainer imho. Regards, Bapt ___ 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 export to git "fatal: mark :60713 not declared"
I reported the exact same bug around 2 month ago without tracking any interest :( regards, Bapt 2014-10-31 23:08 GMT+01:00 E. Timothy Uy : > I was able to import see.fossil and cerod.fossil from Cygwin with no issues. > However for SQLite, > > $ fossil export --git ../../../sqlite.fossil | git fast-import > > fatal: mark :60713 not declared > > fast-import: dumping crash report to > ./.git/modules/src/sqlite/fast_import_crash_1168 > > > > From the crash report: > > fast-import crash report: > > fast-import process: 1168 > > parent process : 1 > > at Fri Oct 31 22:59:48 2014 > > fatal: mark :60713 not declared > > > > commit refs/heads/trunk > > mark :60705 > > committer drh 1257341402 + > > data 83 > > from :60691 > > M 100644 :60706 src/main.c > > M 100644 :60698 src/sqliteInt.h > > commit refs/heads/shunning_error > > mark :60721 > > committer drh 1257360677 + > > data 24 > > * from :60713 > > > > ___ > 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] Playing with ticket in console
Hi, I fail to find a way to play with tickets directly via the cli, am I missing something? I can see how to list reports etc, but I find no way to open,close,comment,grab an attachment from cli (the last part is probably the most important) I really do enjoy the web interface but it is imho really important that all(most) operations available on web interface should be available via the cli (think automation) In my case I'm working on a CI where I notify via th1 changes the CI and automatically grab attached patches if available. regards, Bapt ___ 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] Problem with TH1 hooks
2014-06-19 18:17 GMT+02:00 Joe Mistachkin :
>
> Baptiste Daroussin wrote:
>>
>> I have to repositories, all of which are served by the same version of
>> fossil (1.29 release)
>>
>
> The Fossil 1.29 release does not have the new "TH1 hooks" feature. It does
> have
> TH1 scripting, of course.
>
>>
>> On the second one uuid is not available at all but tkt_uuid has to be
>> used and when I do create a new ticket it fails saying "no such
>> variable: tkt_uuid"
>>
>
> I'm not sure what the precise cause of this error is; however, it may be
> that
> one of the ticket "templates" refers to it when it is not actually available
> (e.g. the ticket view page where there is no "tkt_uuid" column value
> available).
>
> --
> Joe Mistachkin
>
>To be extact I'm talking about admin>tickets/changes I do call that hooks
>because it is executed each time a user is creating/modifying a ticket :) (in
>url form /tktsetup_change)
verry basically here is the code:
query { select group_concat(ticketchng.login," ") as log from
ticketchng, ticket where ticket.tkt_id=ticketchng.tkt_id and
tkt_uuid=$uuid } {
set commenters "$log"
}
if {[string length $private_contact] == 0} { set private_contact anonymous }
http -asynchronous "http://127.0.0.1:8085/ticketwarn";
"\[$project_name: ticket\]
$title\n$commenters\n$private_contact\n$uuid\n$login\n$home\nTicket
modified by: $login\nChanges: $baseurl/tktview/$uuid\n\n"
return
I would expect here $uuid to be generic and always available? perhaps
I'm mistaking and when would be a reliable value that identify the
ticket that was modified/created?
regards,
Bapt
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Problem with TH1 hooks
I have to repositories, all of which are served by the same version of fossil (1.29 release) Both of them are acting differently, when dealing with th1 hooks (admin/tickets/change) On one of them uuid is defined and usable all the time (when creating a ticket or modifying it) On the second one uuid is not available at all but tkt_uuid has to be used and when I do create a new ticket it fails saying "no such variable: tkt_uuid" How is that possible? regards, Bapt ___ 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] Working with large repository
I'll be able to tell you if ever this conversion finishes :) right now 88H and still running @eduardo at the time iirc the git export did not contain the full history but a small part of it, right now for sure it contains the full history 2014-06-17 17:39 GMT+02:00 Stephan Beal : > On Tue, Jun 17, 2014 at 5:30 PM, Eduardo Morras wrote: >> >> git fast-export > xz -vv --lzma2=preset3,dict=256MiB git.xz >> xzcat -vv git.xz > fossil import git.fossil > > > That is a _very_ interesting trick. > > Question to you both: do you know if fossil has generated any delta > manifests in the import? By default fossil does not generate delta > manifests, but they can potentially save space for large repos. Once fossil > has generated _one_ delta, it will allow itself to generate more, but by > default it will never generate any. A delta can be forced at commit time > with --delta, but i don't know if the git import feature (never needed it) > supports something like that. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Working with large repository
Hi, I just want to share some feedback, for fun I tried to convert some of the FreeBSD repositories to fossil to see how it performs I first tried the FreeBSD Documentation repository, to go the easy way I took the FreeBSD git mirror (https://github.com/freebsd/freebsd-doc and run git fast-export --full-tree --all | fossil import --git ../doc.fossil The worked pretty well, and I manage to convert in a few hour the repo, the result it very usable (that wasn't the case a few years ago, some operations where slow) Result is available here: https://fossil.etoilebsd.net/doc if some want to play. At the same time I decided to try with ports and base repository which I would have expected to be a bit more complicated I cloned: https://github.com/freebsd/freebsd and https://github.com/freebsd/freebsd-ports I run the same command for the conversion git fast-export --full-tree --all | fossil import --git ../ports.fossil both are now running for more than 70H and still not finished!!! consuming 100% CPU This is running on pretty descent hardware. hw.model: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz I guess I would have to run a svndump imported manually if I want a slightly faster conversion to happen, and given how the incremental import works with fossil import --git I cannot imagine running a fossil mirror using that tool. If anyone has ideas on how I can maintain a mirror more easily, tips welcome Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Painful team interaction with fossil, how to improve?
Hi, I'm using fossil for a while now, and I'm quite happy with it, for the scm part and the web part. The problem is when going with the ticket part of fossil. I do not need something sophisticated, the the way the ticket works is ok with me, however the more the project I'm working on is growing the more painful it becomes to track ticket activity. In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) 2/ send a mail each time to ticket is modified to reporters and followers (No rss2email is not a solution: not flexible enough) The 2 above are really painful, and for the first time I really thinking about migrating from fossil to $something else for the project I do have the becomes popular :( The lacks of flexible hooks on server side is also a big problem to me, I can live with it, but the more I get people involve in the project I'm working on the more I'm missing it. What I do need on the hook side is: 1/ send a mail after each "push" of code with a diff: prior-push-tip/post-push-tip for each branch impacted to a given mailing list 2/ be able to get access to the diff and run random code on it and reject the push if not validated I would like to be able to do the above on top of fossil, how should I do? regards, Bapt ___ 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] looking for interesting new fossil skins
The timeline does not support multi-line commit message, I sent the patch for the web version of the time line as well as the info page that you integrated, but I was never able to figure out how to do the same with the the timeline cli. For the command line I always messed up in the way I count the numbers of char in multi-line mode so my patched version always end up with a mangled indentation in timeline. 2014-02-12 12:50 GMT+01:00 Stephan Beal : > On Wed, Feb 12, 2014 at 8:40 AM, Baptiste Daroussin < > baptiste.darous...@gmail.com> wrote: > >> I have also stolen long ago the "google code" like theme and has adapted >> it a bit: >> - timeline is showing "raw" logs (because we do multiline commit logs - >> btw I can't get the cli timeline respecting multiline commits log :() >> > > That timeline looks pretty nice in multi-line mode. IIRC the CLI does not > have any option to specially handle multi-line commit messages. > > >> - the tree view is default and has icons (stolen from openclipart as >> well) which makes it "better integrated" in the global theme) >> > > That also looks nice. i'll have to study your CSS to see how to do that. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ 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] looking for interesting new fossil skins
I have also stolen long ago the "google code" like theme and has adapted it a bit: - timeline is showing "raw" logs (because we do multiline commit logs - btw I can't get the cli timeline respecting multiline commits log :() - the tree view is default and has icons (stolen from openclipart as well) which makes it "better integrated" in the global theme) https://fossil.etoilebsd.net/poudriere regards, Bapt 2014-02-11 21:36 GMT+01:00 Stephan Beal : > On Tue, Feb 11, 2014 at 7:42 PM, Martijn Coppoolse < > li...@martijn.coppoolse.com> wrote: > >> Another one I liked is this one: >> http://projects.depar.is/divers/ >> >> It's based on GitHub's style, as the one above is based on Google Code's >> style. :-) > > > Oooo, i like that one, too, but Google Code sits fonder in my memory than > git-anything ;), so i'm sticking with the bluish one for now. > > Sidebar: i (re)discovered today that (fossil config export skin) exports > the index-page setting and imports it on (fossil config import). index-page > apparently cannot be set via the CLI, meaning that manual GUI intervention > is needed when importing the config to a repo which has a different index > page name (as most do). i find copying this option as part of the skin to > be somewhat arguable (though a use case for it could certainly present > itself)./Sidebar > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Customs mime-type
Hi all, Is there a way to define custom mime type for fossil serve? I want for example .patch and .sh to return text/plain instead of application/x-fossil-artifact. when I hit it like this: http://fossil.etoilebsd.net/ports-patches/doc/trunk/gmake.patch Is there a way? regards, Baptg ___ 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] Is anyone letting "nobody" download ZIP files?
I do use nobody to download zip, and this is the way I do distribute some releases with out having the need of having to host a distfile somewhere, that is pretty convenient. So far no problems at all. regards, Bapt 2013/6/11 Stephan Beal > On Tue, Jun 11, 2013 at 12:01 PM, Stephan Beal wrote: > >> On Tue, Jun 11, 2013 at 12:39 AM, Richard Hipp wrote: >> >>> Both Fossil and SQLite allow user "nobody" to download ZIP archives and >>> tarballs. Bots have not been a problem there, due to the spider defenses. >>> See http://www.fossil-scm.org/fossil/doc/trunk/www/antibot.wiki for a >>> detailed description of the spider defenses. >>> >> >> The delayed setting of href until a mouseover is a really clever idea :). >> > > Another idea might be to set the href to the HTTP Referrer (if set) when > we strongly suspect that it's a bot. That way any following of the links > leads them off-site. > > -- > - 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 > > ___ 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] Annotate really slow and eating 100% CPU
2013/3/14 Richard Hipp : > > > On Thu, Mar 14, 2013 at 4:02 PM, Richard Hipp wrote: >> >> >> Hmm If you add the "log" query parameter, the annotator also shows you >> which check-ins it examined in order to compute the annotation. If I add >> &log&limit=800 (see >> https://fossil.etoilebsd.net/poudriere/annotate?checkin=bbbfd3a9d07e6690&filename=src/share/poudriere/common.sh&limit=800&log) >> and if you scroll down, you can see that the annotator really does enter an >> endless loop starting at about 716. I'll see if I can fix that > > > I fix for the inifinite annotator loop has been checked in. > > Wow that was fast thank you very much! And thanks for the explanations. regards, Bapt ___ 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] Annotate really slow and eating 100% CPU
2013/3/14 Richard Hipp : > > > On Thu, Mar 14, 2013 at 3:37 PM, Richard Hipp wrote: >> >> >> >> Regarding that last file, if you visit >> https://fossil.etoilebsd.net/poudriere/finfo?name=src%2Fpoudriere.d%2Fcommon.sh >> and scroll to the bottom of the page, it looks as if there is a loop in the >> history of that file. I'm not sure how that loop got there. (Possible this >> has something to do with the git import.) But the annotator might be stuck >> in that loop. > > > Digging further, I not that the "full" display of file history does not show > the loop. Scroll to the bottom of > https://fossil.etoilebsd.net/poudriere/finfo?fco=0&name=src/poudriere.d/common.sh > to see this. > > The apparently loop is likely just a display problem that seems to originate > with the huge timewarp that got inserted upon import. Scroll down on this > timeline: > > > https://fossil.etoilebsd.net/poudriere/timeline?n=200&c=2010-08-27+21:41:59 > > to see the timewarp. > > The timewarp is likely a git->fossil conversion bug. (Not necessarily a > fossil bug, as there is no shortage of bugs in git-fast-export). It might > be worth while try to trace down this import bug. If you can give us any > clues, that would be appreciated. > > Would be hard it was very long time ago and I don't have anymore the original git repo. I dropped it as soon as I jumped on fossil :) All I have is the repository itself. What kind of informations can I provide you that may be helpful regards, Bapt ___ 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 scrub --private leading to a broken repository
2013/2/25 Richard Hipp : > > > On Mon, Feb 25, 2013 at 11:09 AM, Baptiste Daroussin > wrote: >> >> Hi, >> >> I have been using a private branch to test some code like this: > > > > Please try again after this patch: > http://www.fossil-scm.org/fossil/info/60acc2de34 > Works as expected now, thank you very much. Sorry it was long before I was able to test. regards, Bapt ___ 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 scrub --private leading to a broken repository
2013/2/25 Stephan Beal :
> Here's a reproduce with backtrace (Ubuntu 12.04/x64)...
>
> On Mon, Feb 25, 2013 at 5:09 PM, Baptiste Daroussin
> wrote:
>>
>> fossil ci --private -m "test2"
>> fossil merge private
>
>
> did you check out trunk between that? When i ci --private (trying to
> reproduce this) i am moved to the 'private' branch.
Yes, below is the exacte reproduction of the bug I just got.
Is there a way to recover from that or I should reclone the repository?
regards,
Bapt
>
> [stephan@host:~/cvs/fossil/priv]$ f com --private -m two
> New_Version: 642fa51e511023058279683114518919fa152862
> [stephan@host:~/cvs/fossil/priv]$ f merge private
> Fossil internal error: lack both primary and secondary files
>
> i would expect an error when trying to merge into itself.
>
> [stephan@host:~/cvs/fossil/priv]$ f co trunk
> [stephan@host:~/cvs/fossil/priv]$ f merge private
> ADDED hosts
> "fossil undo" is available to undo changes to the working checkout.
>
> [stephan@host:~/cvs/fossil/priv]$ f com -m foo
> New_Version: fa09ed1e016bb8505525647a184d88b885977a8a
> [stephan@host:~/cvs/fossil/priv]$ f scrub --private
> Scrubbing the repository will permanently delete information.
> Changes cannot be undone. Continue (y/N)? y
> 0.0% complete...
> SQLITE_ERROR: no such table: main.delta
> SQLITE_ERROR: duplicate column name: mtime
> SQLITE_ERROR: duplicate column name: mtime
> SQLITE_ERROR: duplicate column name: mtime
> 100.0% complete...
> [stephan@host:~/cvs/fossil/priv]$ fst
> Segmentation fault (core dumped)
> [stephan@host:~/cvs/fossil/priv]$ gdb --args f status
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.launchpad.net/gdb-linaro/>...
> Reading symbols from /home/stephan/bin/f...done.
> (gdb) r
> Starting program: /home/stephan/bin/f status
>
> Program received signal SIGSEGV, Segmentation fault.
> strglob (zGlob=0x4fb0a8 "isexe *", z=0x0) at ./src/glob.c:173
> 173 while( (c2 = (*(z++)))!=0 ){
> (gdb) bt
> #0 strglob (zGlob=0x4fb0a8 "isexe *", z=0x0) at ./src/glob.c:173
> #1 0x0041c939 in isValidLocalDb (zDbName=0x7fffd9e0
> "/home/stephan/cvs/fossil/priv/.fslckout") at ./src/db.c:892
> #2 db_open_local () at ./src/db.c:945
> #3 0x0041cae9 in db_must_be_within_tree () at ./src/db.c:1153
> #4 0x00412449 in status_cmd () at ./src/checkin.c:204
> #5 0x00407921 in main (argc=, argv=)
> at ./src/main.c:600
>
> --
> - 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
>
___
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] sqlite errors after reinstalling fossil
2013/1/18 Joseph Mingrone : > On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp wrote: >> I don't know why not... Did you start from fresh sources? What did you do >> to get the error below? > > Apparently I didn't start from fresh sources or I messed something > else up. After... > > tar -xf tar -xvf fossil-src-20121022124804.tar.gz > cd fossil-src-20121022124804/src/ > fetch > 'http://www.fossil-scm.org/fossil/raw/src/db.c?name=1b058e27e61edc91b7a5ce404ac5add09328b16d' > cd .. > ./configure > gmake > > It compiles fine. But, in the same directory I just did: > > fossil init blah > > and I get the same error. > > Joseph > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Your failure is the following: fcntl(4,F_SETLK,0x7fffcca0) ERR#45 'Operation not supported' Something is wrong about your nfs setup imho regards, Bapt ___ 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] sqlite errors after reinstalling fossil
2013/1/18 Joseph Mingrone : > On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp wrote: >> Please try again using the patch to Fossil I just now checked in: >> >> http://www.fossil-scm.org/fossil/info/7536c6aea5 > > It didn't compile for me. > > ... > cc -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -o bld/db.o -c bld/db_.c > ./src/db.c: In function 'db_open_config': > ./src/db.c:819: error: 'Global' has no member named 'zConfigDbType' > ./src/db.c:823: error: 'Global' has no member named 'zConfigDbType' > ./src/db.c: In function 'db_close': > ./src/db.c:1193: error: 'Global' has no member named 'zConfigDbType' > ./src/db.c: In function 'db_swap_connections': > ./src/db.c:1669: error: 'Global' has no member named 'zConfigDbType' > ./src/db.c:1671: error: 'Global' has no member named 'zConfigDbType' > gmake: *** [bld/db.o] Error 1 > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Can you host somewhere the file.out created by truss -o file.out fossil init bla ? regards, Bapt (maintainer of fossil for FreeBSD) ___ 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] New regexp OpenBSD build error
2013/1/2 Stephan Beal : > On Wed, Jan 2, 2013 at 8:56 AM, Baptiste Daroussin > wrote: >> >> 2013/1/2 James Turner : >> ... >> in.mx = nIn>=0 ? nIn : strlen(zIn); > > ... >> >> pRe->sIn.mx = strlen(pRe->sIn.z); > > > those are fixed now, too. Thanks again for the report. > > http://fossil-scm.org/index.html/info/46af6b8260 > > -- > - 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 > Thanks it now builds and works without any warnings on FreeBSD Bapt ___ 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] New regexp OpenBSD build error
2013/1/2 James Turner :
> On OpenBSD re_exec is already defined in unistd.h causing the latest
> trunk to fail to build.
>
> In file included from ./src/diff.c:22:
> bld/diff.h:287: error: conflicting types for 're_exec'
> /usr/include/unistd.h:478: error: previous declaration of 're_exec' was
> here
> *** Error 1 in /home/james/code/fossil (./src/main.mk:557 'bld/diff.o')
>
> It's obsolete but sadly still present.
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=re_exec&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
>
Same on FreeBSD,
Here is a patch to rename the re_exec to re_execute and make the code
compilable on FreeBSD.
http://people.freebsd.org/~bapt/re_exec.diff
While here I don't know what are the rules about the warnings, but I'm
building fossil with clang and I a couple of warnings.
For the test, I run configure --json --markdown
If you think it is worth fixing those, I can provide a patch, next
week (I'll be off the rest of the week)
./src/diff.c:428:25: warning: passing 'const char *' to parameter of
type 'const unsigned char *' converts between pointers to integer
types with different sign [-Wpointer-sign]
if( re_execute(pRe, aDLine->z, LENGTH(aDLine)) ){
^
bld/diff.h:287:53: note: passing argument to parameter 'zIn' here
int re_execute(ReCompiled *pRe,const unsigned char *zIn,int nIn);
^
In file included from ./src/json_timeline.c:21:
bld/json_timeline.h:329:12: warning: duplicate 'const' declaration
specifier [-Wduplicate-decl-specifier]
const char const *json_timeline_query(void);
^
./src/json_timeline.c:95:12: warning: duplicate 'const' declaration
specifier [-Wduplicate-decl-specifier]
const char const * json_timeline_query(void){
^
2 warnings generated.
./src/regexp.c:196:33: warning: passing 'const unsigned char *' to
parameter of type 'const char *' converts between pointers to integer
types with different sign [-Wpointer-sign]
in.mx = nIn>=0 ? nIn : strlen(zIn);
^~~
/usr/include/string.h:92:28: note: passing argument to parameter here
size_t strlen(const char *) __pure;
^
./src/regexp.c:631:24: warning: passing 'const unsigned char *' to
parameter of type 'const char *' converts between pointers to integer
types with different sign [-Wpointer-sign]
pRe->sIn.mx = strlen(pRe->sIn.z);
^~
/usr/include/string.h:92:28: note: passing argument to parameter here
size_t strlen(const char *) __pure;
^
2 warnings generated.
./src/cson_amalgamation.c:4385:20: warning: comparison of unsigned
expression < 0 is always false [-Wtautological-compare]
if( ! arg || (n<0) ) return cson_rc.ArgError;
~^~
1 warning generated.
regards,
Bapt
___
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 version 1.25 scheduled.
2012/11/30 Richard Hipp > I have put up a change log for Fossil version 1.25 with a tentative > release date of 2012-12-19 > > http://www.fossil-scm.org/fossil/doc/trunk/www/changes.wiki > > There has been a *lot* of change since 1.24. Please test the trunk > version of Fossil as you are able to. Report any issues to this mailing > list, or file a ticket. We want 1.25 to be a good release, but we need > your help in testing in order to accomplish that. > > FWIW, we do eat our own dogfood. The Fossil executable that runs the > Fossil website gets updated to the tip of trunk roughly every day. The > same executable also runs http://www.sqlite.org/ and several other > websites. And all of my personal machines (linux, mac, and windows) are > running the very latest Fossil code. If there were serious problems with > the latest Fossil code, I would be doomed. You can trust that the tip of > trunk is reasonably stable. Nevertheless, I'm sure if hundreds of you > start testing the latest code, some of you will run across various minor > issues, issues that we would prefer to fix prior to 1.25 instead of after. > Therefore, do please test. Thanks. I have been testing the latest trunk on FreeBSD (so far far no problem spotted) thank you very much, I am a big user of fossil on FreeBSD and really happy with it :) I haven't followed the developpement recently, but was hopping a markdown integration for 1.25 given that a branch for markdown integration has been created month ago. So sorry to bother you again with this, but is there any status for this particular thing? regards, Bapt ___ 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] Markdown engine integrated into fossil
2012/7/9 Richard Hipp : > > > On Mon, Jul 9, 2012 at 3:31 AM, Baptiste Daroussin > wrote: >> >> 2012/6/7 Richard Hipp : >> > >> > >> > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin >> > wrote: >> >> >> >> Is there any status on this? rejected ? still under review ? >> > >> > >> > DRH swamped. But it is on the list of potential changes for the Fossil >> > Code >> > Sprint in Munich on July 3! >> > >> >> Reading at the feeback from Munich, this obviously didn't happened :) > > > Yeah. Unfortunately, no actual code writing took place at the "code > sprint." Though lots of cool ideas were exchanged and developed! > Yeah I've seen that :). > >> >> is there still plan on it, (btw the library seems to have been fully >> renamed to libsoldout) > > > There are lots of nice features that people want, but I have limited time to > work on them. Perhaps there can be volunteers. > She volunteers and did the job :) > My priority is to get WYSIWYG wiki editing going, at which point the > underlying wiki formatting language becomes largely irrelevant, no? > Not for me as I want to use "in trunk" documentation, and edit it with my favorite $EDITOR :) WYSIWYG doesn't fit my needs at all, plus I have some automated chains using markdown, so having my documentation written only once would be great. Anyway I can wait or live without it, just it will easier maintaining some of my projects. regards, Bapt ___ 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] Markdown engine integrated into fossil
2012/6/7 Richard Hipp : > > > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin > wrote: >> >> Is there any status on this? rejected ? still under review ? > > > DRH swamped. But it is on the list of potential changes for the Fossil Code > Sprint in Munich on July 3! > Reading at the feeback from Munich, this obviously didn't happened :) is there still plan on it, (btw the library seems to have been fully renamed to libsoldout) Sorry for insisting on this features, but I would love so much to be able to write my documentation in markdown :D regards, Bapt ___ 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] Markdown engine integrated into fossil
Is there any status on this? rejected ? still under review ? regards, Bapt ___ 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] Markdown engine integrated into fossil
> The choice of library name suggests that the author does not have a keen eye > for beauty, in which case the code is unlikely to be something I would care > to work with. Maybe the name of the library just don't represent the same for the author as for you, different culture, etc; but this really have nothing to do with having a keen eye for beauty. > Furthermore, I am disinclined to look at the code for fear of running across > comments that I would prefer not to read. You should really have a look at the code, it was written far before the name of the library, and there are no comments of any kind like you seem to imagine. This is to bad that this great library is just pushed out because of an unfortunate name which was chosen for a joke (with references, that apparently noone from the native english speaking world get) and with out any perverse references in mind. Please have a look at the code before judging of anything about the author, just judge the code and work she has done. You don't even have to name the library on the commit log, just "New markdown format support for embedded documentation or something like that". And if the name is a problem, I'm pretty sure she could easily be convinced to change the name of the library if someone come with a better name. Nothing in the code itself reference libupskirt regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Changing password for a developper?
Hi, I was adding some new developper to my fossil repositories, and figured out that a developper was not able to change his password using the web interface using default rights? is there a way to activate this? regards, Bapt ___ 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] Supporting markwon syntax for wiki
Le 27 avril 2012 12:14, Natacha Porté a écrit : > Hello, > > on Thursday 26 April 2012 at 00:53, Ivan Vilata i Balaguer wrote: >> chris (2012-04-22 17:09:45 +0200) wrote: >> >> > Please check out >> > >> > https://server.ac-drexler.de/fossil/fossil/doc/tip/addons/markdown.md >> > >> > for an integration proposal of the discount library with the build >> > system of fossil. >> > >> > --- >> > ## Markdown support for fossil >> > >> > after looking for additional markup support for fossil I found [this >> > thread][1]. With the references and some afternoon work I managed to >> > integrate Markdown as an additional mime-type .md that the doc >> > interface handles in a similar way to .wiki& .txt. >> >> Looks nice! You may also be interested in my enhanced version of Bill >> Burdick's Fossil pagedown software which does client-side rendering of >> wiki pages and embedded `.wiki` and `.txt` docs starting with >> `@pagedown` and (similarly to your solution) all embedded docs ending in >> `.md.txt` (of course with no changes at all to Fossil and keeping repos >> portable). > > Since we are talking about alternatives for markdown-in-fossil, you > might remember my repeated mentions about integrating my [markdown > library][libupskirt] into fossil. > > To be perfectly honest, I lost interest in the idea, and went for the > generated embedded docs idea (same as what was previously said with > AsciiDoc). Even though I still don't like putting generated stuff into > the SCM, I find it to be a lesser evil compared to the risk of > spectacular failure when embedding such complex code into fossil, > especially with regard to security (since it's the same binary, a > vulnerability in the markdown code can mean read/write access to at > least the whole sqlite database). > > So my question is now, is there anybody willing to take it over, or do I > just send it to the heaven for bits? > > For the record, I think the main pros my library still has over discount > is legal stuff (I can hand over copyright of fossil's fork any time) and > direct support from me. However these are probably not worth much if > merge into official release is still not going to happen. > Well performance is also very good point for your library, it out performs discount by far and consumes far less memory. regards, Bapt ___ 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] New CSS on the Fossil homepage
2012/3/31 Richard Hipp : > > > On Sat, Mar 31, 2012 at 12:13 PM, Baptiste Daroussin > wrote: >> >> 2012/3/31 Stephan Beal : >> > On Sat, Mar 31, 2012 at 5:37 PM, Richard Hipp wrote: >> >> >> >> I have succumbed to the temptations of eye-candy. Please offer your >> >> thoughts and constructive comments on the new look of the Fossil >> >> website >> >> versus the previous style. >> > >> > >> > i like the corners, but the background seems a bit too 1998. i like the >> > rotated skeleton, too. My roommate says the background clashes too much >> > with >> > the site's colors. >> > >> > -- >> > - stephan beal >> > http://wanderinghorse.net/home/stephan/ >> > http://gplus.to/sgbeal >> > >> >> Everything is nice, but please forget about the background :) > > > > So now I have three variants up for consideration: > > (1) http://www.fossil-scm.org/ > (2) http://www2.fossil-scm.org/ > (3) http://www3.fossil-scm.org/ > > #1 is the recent change, with the rock background, which I (being very old > school) prefer. #2 is the original before recent changes. #3 is like #1 > but without the background image. > > Please continue with feedback. > I do prefer #3. regards, Bapt ___ 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] New CSS on the Fossil homepage
2012/3/31 Stephan Beal : > On Sat, Mar 31, 2012 at 5:37 PM, Richard Hipp wrote: >> >> I have succumbed to the temptations of eye-candy. Please offer your >> thoughts and constructive comments on the new look of the Fossil website >> versus the previous style. > > > i like the corners, but the background seems a bit too 1998. i like the > rotated skeleton, too. My roommate says the background clashes too much with > the site's colors. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > Everything is nice, but please forget about the background :) ___ 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] Can't build from 1.22 release tarball
2012/3/17 Christopher Berardi : > On Sat, Mar 17, 2012 at 06:46:35PM -0400, James Turner wrote: >> Untar 1.22 release tarball [0] run ./configure then make which fails >> with: >> >> make: *** No rule to make target `src/../manifest.uuid', needed by >> `bld/VERSION.h'. Stop. >> >> [0] http://www.fossil-scm.org/download/fossil-src-20120317175325.tar.gz >> > > Same here. > Confirmed on FreeBSD. regards, Bapt ___ 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 completion for Zsh
2012/1/27 Mike Meyer : > On Fri, 27 Jan 2012 07:48:09 + > Baptiste Daroussin wrote: >> Nice one usually the zsh project prefers to have it incorporate >> upstream so do not hesitate to send your contribution to the >> zsh-workers mailing list also and because you are working on >> zsh+fossil did you already have a look at vcs_info to add support for >> fossil in it? > > I wrote that a while back (it was announced on the list). You can find > it here: > > http://chiselapp.com/user/mwm/repository/vcs_info/doc/tip/README.wiki > > I gave it back to zsh, but it doesn't seem to be in releases just yet. > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil completion for Zsh
2012/1/27 MIURA Masahiro : > Hi, > > I have created a simple Fossil completion file for Zsh. > https://github.com/Dubhead/Fossil-completion-for-Zsh > > Enjoy :-) > Nice one usually the zsh project prefers to have it incorporate upstream so do not hesitate to send your contribution to the zsh-workers mailing list also and because you are working on zsh+fossil did you already have a look at vcs_info to add support for fossil in it? regards, Bapt ___ 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] How to set up a server under nginx ?
2011/9/25 Richard Hipp : > > > On Sun, Sep 25, 2011 at 12:25 PM, i wrote: >> >> in fact , I want to make several repositories use one port, and under >> nginx. or with CGI anyway.. >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > > (1) Put all of your Fossil repositories in the same directory. For example > /home/www/repos. Name each with the ".fossil" suffix. So, for example, you > might have /home/www/repos/aaa.fossil, /home/www/repos/bbb.fossil, > /home/www/repos/ccc.fossil, and so forth. > > (2) Run "fossil server /home/www/repos". By giving it a directory as an > argument, it will serve any fossil repository under that directory, using > the base name of the repository as the prefix on the URL. Example: > http://localhost:8080/aaa/timeline, http://localhost:8080/bbb/timeline, etc. > I know this is not the place for feature request :), but it will be great if there could be an index of repositories when going to http://localhost:8080/ (ala cgit) regards, Bapt ___ 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] Prototype JSON wiki editor demo online
> So there's the markdown support some of you have been asking for. :) Sorry for stupid question but does that mean that you bundled a markdown library? if yes which one? Or how do you render the markdown? regards, Bapt ___ 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] Supporting markwon syntax for wiki
2011/7/20 Remigiusz Modrzejewski : > > On Jul 20, 2011, at 21:18 , Eric wrote: > >>> +1 >> >> Oh, for heaven's sake! We did this before: >> >> 1) there's no pleasing everybody (we all have our different favourites) > > But most people agree that any of markdown/restructuredtext/dokuwiki/whatever > simple syntax is nicer than html-based markup. > >> 2) if its not available as a single-file C API, it's probably not going in >> anyway (and insisting that it be a library is just as restrictive) > > > At some point of this discussion there was an author willing to contribute > his (her?) markdown-mangling C code. But this author did not want to delve > into inner workings of Fossil, only offered code with good license and help > to whoever integrates that. But nobody volunteered to be the integrator. This is wrong she volunteered to be the integrator she was just asking some help to work with in inner of fossil to be sure she does the things the right way, and the way richard would be happy with. Her code is closed to single C file to integrate, it out performs discout from my testing. Have a look. http://fossil.instinctive.eu/libupskirt/index And the more important it is really very easy to use. Anyway richard seems to have decided that there won't be any support for markdown in fossil. regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Supporting markwon syntax for wiki
Hi, Is there any thought on supporting markdown as a wiki format for fossil? For information there is a fast, simple and easy to use library (license BSD 2 clauses) that maybe used for that: http://fossil.instinctive.eu/libupskirt/home it is easy to bundle if desired. Markdown is a really simple format that would imho greatly improve the embed wiki of fossil. regards, Bapt ___ 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] Version scheme
2011/2/10 Gour : > On Thu, 10 Feb 2011 11:24:38 +0100 Baptiste Daroussin wrote: > >> I'm maintainer of the freebsd package for fossil > > I plan to move from Linux to Free(PC)BSD soon, so I'm glad to see > Fossil is nicely supported there. ;) > At least I find it usable here :) and got not complain from users. >> Do you plan to often change or not ? I ask just to be able to keep >> version scheme clear for the package. > > Otoh, when we speak about Fossil's versioning, I believe it's stable > enough to adapt versioning scheme used e.g. in Sqlite which would, > imho, make life easier for packagers as well as for end-users. > A date based version is ok for packager, the porblem is only to be able to determine that n+1 is really > n and 20110113195528947 > 20110208125237 but n+1 is 20110208125237 and n is 20110113195528947 regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Version scheme
Hi, I'm maintainer of the freebsd package for fossil http://www.freshports.org/devel/fossil until now the version scheme was something like: MMDDHHMMSS but the lasted january release version scheme was : MMDDHHMMSSmmm, now (as frebruary release) is back to the old scheme. Do you plan to often change or not ? I ask just to be able to keep version scheme clear for the package. regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
