[fossil-users] diff command and 'permission denied'
Hello, I'm working on a simple course - using markdown markup for text files and store few pdf files. I changed settings for 'diff' command to 'meld', but then reverted back to use built-in diff for 'diff' command and 'meld for gdiff/gmerge. However, Fossil is now complaining... See the output: $ fossil chan EDITED 2.md $ fossil diff Index: 2.md == sh: 1: /home/gour/prj/iching/2.md~0: Permission denied $ fossil gdiff Index: 2.md == (it launches meld here) $ ls -al total 56 drwxr-xr-x 1 gour gour74 Srp 26 12:23 ./ drwxr-xr-x 1 gour gour 230 Srp 24 12:34 ../ -rw-r--r-- 1 gour gour 3478 Srp 25 11:55 1.md -rw-r--r-- 1 gour gour 6370 Srp 26 11:47 2.md -rw-r--r-- 1 gour gour 7168 Srp 26 12:04 .fslckout -rw-r--r-- 1 gour gour 10277 Srp 26 10:01 h24.pdf -rw-r--r-- 1 gour gour 10800 Srp 24 12:44 h4.pdf -rw-r--r-- 1 gour gour 11222 Srp 26 09:59 h51.pdf $ fossil settings access-log allow-symlinks auto-captcha auto-hyperlink auto-shun autosync (local) 1 autosync-tries binary-glob (local) *.pdf clearsign(local) 1 case-sensitive clean-glob crnl-glob default-perms diff-binary diff-command (local) dont-push editor (local) emacsclient -t empty-dirs encoding-glob gdiff-command(local) meld gmerge-command (local) meld http-port https-login ignore-glob keep-glob localauth(local) 0 main-branch manifest max-loadavg max-upload mtime-changes pgp-command proxy relative-paths repo-cksum self-register ssh-command ssl-ca-location ssl-identity th1-hooks th1-setup th1-uri-regexp web-browser white-foreground Any hint how to get rid of that 'Permission denied' error and make (built-in) diff to work again? Sincerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. ___ 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] diff command and 'permission denied'
On Sat, Jul 26, 2014 at 12:26 PM, Gour g...@atmarama.net wrote: $ fossil chan EDITED 2.md $ fossil diff (it launches meld here) $ fossil settings gdiff-command(local) meld Weird. i can't reproduce that on my system: [stephan@host:~/cvs/fossil/fossil]$ f set gdiff gdiff-command(global) meld [stephan@host:~/cvs/fossil/fossil]$ f diff Index: Makefile.classic == --- Makefile.classic +++ Makefile.classic @@ -71,5 +71,6 @@ TCC.NetBSD += -DUSE_PREAD TCC.OpenBSD += -DUSE_PREAD TCC += $(TCC.$(HOST_OS)) include $(SRCDIR)/main.mk +# test [stephan@host:~/cvs/fossil/fossil]$ f gdiff Index: Makefile.classic == meld... [stephan@host:~/cvs/fossil/fossil]$ f set | grep diff diff-binary diff-command gdiff-command(global) meld This probably won't help, as your ls listing shows us that file doesn't exist, but can you try: rm '/home/gour/prj/iching/2.md~0' (with the quotes) What platform is this? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] diff command and 'permission denied'
Stephan Beal sgb...@googlemail.com writes: This probably won't help, as your ls listing shows us that file doesn't exist, but can you try: rm '/home/gour/prj/iching/2.md~0' Of course, rm: cannot remove ‘/home/gour/prj/iching/2.md~0’: No such file or directory What platform is this? Linux x86_64 Debian (Sid), fish shell. I can send/upload repo if you want? Sincerely, Gour -- Just try to learn the truth by approaching a spiritual master. Inquire from him submissively and render service unto him. The self-realized souls can impart knowledge unto you because they have seen the truth. ___ 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] diff command and 'permission denied'
On 26 July 2014 12:26, Gour g...@atmarama.net wrote: Hello, I'm working on a simple course - using markdown markup for text files and store few pdf files. I changed settings for 'diff' command to 'meld', but then reverted back to use built-in diff for 'diff' command and 'meld for gdiff/gmerge. However, Fossil is now complaining... See the output: $ fossil chan EDITED 2.md $ fossil diff Index: 2.md == sh: 1: /home/gour/prj/iching/2.md~0: Permission denied $ fossil gdiff Index: 2.md == I can reproduce it here when setting 'diff-command' to the empty string. Perhaps you have done that too (from the looks of 'fossil set' output). You can unset an option using 'fossil unset'. Michai ___ 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] diff command and 'permission denied'
On Sat, Jul 26, 2014 at 1:03 PM, Michai Ramakers m.ramak...@gmail.com wrote: I can reproduce it here when setting 'diff-command' to the empty string. Perhaps you have done that too (from the looks of 'fossil set' output). You can unset an option using 'fossil unset'. Good catch! Does fossil need to always treat an empty string as an unset operation, or are there cases where an empty string is a useful value? -- - 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] fossil vs git-based arrangements. code review and ticket export
I'm starting a company with some folks. Their notion of the default choice for SCM is git + JIRA for bug tracking + some other tool we'd pick for code review. This is probably quite common. Since the answers to my questions will probably be interesting to a relatively wide audience, I hope the forum will forgive the length of my post. By 'code review' here I mean a web-based tool that has a formalized state machine for (a) uploading code deltas (b) filing and fixing defects against the uploaded code and (c) having the right set of people sign off. Like Code Collaborator. I guess JIRA has an integrated tool that is free for small teams too. Whatever. It just needs to eventually support reviewing every line of code that gets written, in case we decide to go in that direction. I'm trying to convince my co-founders to use fossil. I won't address all of fossil's strengths, since you will all agree with me. I want you to give me some ammunition on the weaker points: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? * Code review! DRH has said on this forum (and I'm paraphrasing here) that he prefers to review humans more than code. If he decides he trusts the human, then he mostly trusts the human's output. So he didn't really care to write a native tool for code review for Fossil. This is what I think I need the most help with. While I feel mostly the same as DRH on the matter, I also would like to have a story in case one day the team decides they want to have every line go through a review process. If I don't have a story up front for that then it will be a biasing factor against Fossil, since it will be more likely we'd need to go through a transition (one they would worry is onerous or error-prone) to some other SCM in the future. I've come up with some work-flows that sort of simulate code reviews right from within fossil. For example, you might make each of your check-ins on its own branch, and when that check-in is accepted it gets merged into the feature branch. The existence of a pending review is signaled by a naming convention on the branches; devs are trained to do an 'lsbranch | grep conventional name' every X days or whatever. Defects are filed by writing comments right into the code under a certain convention and checking in the commented code against the review branch. This still leaves a lot to be desired (e.g. it's very awkward at best for reviewers to write defects, assign severities to the defects and so on). My major questions here are: (1) I know the fossil devs had considered writing a native proper code review feature. Is that anywhere on the near-term road map? (2) Are there 3rd-party code review tools that (a) are good and (b) support fossil? (3) Are there clever work-flows using native fossil features that more closely resemble proper code review tools than the sort of bad one that I sketched above? Thanks! Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Sat, Jul 26, 2014 at 10:53 AM, Eric Rubin-Smith eas@gmail.com wrote: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? Is there a better story for moving between any two bug tracking systems? Do there exist any two bug tracking systems in the world were you can move from one to the other without having to write some scripts to transform the data? Fossil can give you the ticket data as SQL. I think that is probably about as portable as ticket data is going to get. You can use the fossil sql command to run .dump to get the ticket content and then load that content into *any* SQL database (MySQL, PostgreSQL, Oracle, SQL Server - name your poison) You will then have to transform the schema into whatever your target system expects. But I think that is always going to be the case, no? * Code review! My major questions here are: (1) I know the fossil devs had considered writing a native proper code review feature. Is that anywhere on the near-term road map? We do low-ceremony code review on SQLite. Questionable changes go into a branch and then everybody beats on that branch to try to break it and/or find dodgy coding practices, until at some point (perhaps) we think it is ready to go on trunk, at which point it gets merged. There are no review forms to fill out and no records are kept, other than the merge history. For quicker changes, we run fossil diff --tk then use the SaveAs button on the GUI display to create a graphical diff file. We then send that graphical diff file to everybody on our private chatroom. Our homemade chat client recognizes the graphical diff files when they appear as an attachment in the dialog and gives us a button to click to bring up the GUI display. This make it easy for everybody to look over the diff and voice their opinions. Again, there are no forms to fill out and no records are kept, other than the chat logs. If you want more ceremony, you can certainly set up a system in Fossil where changes have to be tagged by the code reviewers, using a PGP-signed tag. That was my original concept for reviews, but not having a need for them, I never actually implemented it. We use more ceremony for testing. We have a (continuously evolving) checklist of tests that we have to work through for each release. See http://www.sqlite.org/checklists/ for a list of recent checklists. If you are a developer (and know the right passwords) you can click on these checklists to make changes, such as to record that a retest is running or to report that a test passed or failed. The checklist management software keeps track of all changes by timestamp, username, and IP address, and we save all that as part of the permanent record. It has been suggested that some kind of checklist facility like this be added to Fossil, but so far the checklist manager is a completely separate program. I find that using a checklist is better than completely automating the tests using something like Jenkins. It is good to keep a human in the loop. Often a test will pass but upon glancing at the output we realize something is wrong and needs to be fixed. Or maybe the test is just taking too long, suggesting a performance regression. Test automation is good. Many of the SQLite testing checklist items are highly automated tests that run literally for hours and perform tens of millions of individual test cases. But even with all this automation, it seems good to have actual humans monitoring the tests for unexpected behavior, and intervening as necessary, and the checklist facilitates that. The checklists also gives us an historical record of the testing, which becomes part of our process documentation. (2) Are there 3rd-party code review tools that (a) are good and (b) support fossil? (3) Are there clever work-flows using native fossil features that more closely resemble proper code review tools than the sort of bad one that I sketched above? Thanks! Eric ___ 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
Re: [fossil-users] diff command and 'permission denied'
Thus said Gour on Sat, 26 Jul 2014 13:18:59 +0200: Maybe fossil's ui should be able to do the same? It can. Run ``fossil ui'' and browse to Admin-Settings Andy -- TAI64 timestamp: 400053d3ce0e ___ 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] diff command and 'permission denied'
Andy Bradford amb-fos...@bradfords.org writes: It can. Run ``fossil ui'' and browse to Admin-Settings Well, the error is result of applying 'fossil ui' on diff-command settting. ;) Sincerely, Gour -- Before giving up this present body, if one is able to tolerate the urges of the material senses and check the force of desire and anger, he is well situated and is happy in this world. ___ 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] diff command and 'permission denied'
On 26 July 2014 18:53, Gour g...@atmarama.net wrote: Andy Bradford amb-fos...@bradfords.org writes: It can. Run ``fossil ui'' and browse to Admin-Settings Well, the error is result of applying 'fossil ui' on diff-command settting. ;) The issue here is that you cannot unset a variable through the UI; you can only set it to the empty string, right? Michai ___ 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] diff command and 'permission denied'
Michai Ramakers m.ramak...@gmail.com writes: The issue here is that you cannot unset a variable through the UI; you can only set it to the empty string, right? Correct...and that produces error as demonstrated here. Sincerely, Gour -- As a lamp in a windless place does not waver, so the transcendentalist, whose mind is controlled, remains always steady in his meditation on the transcendent self. ___ 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 is now 7 years old
Quotable: I must say that Fossil is the best thing to happen to my development workflow this year, as I am pretty sure that using Git has resulted in the premature death of too many of my brain cells. I'm glad to be able to replace Git in every place that I possibly can with Fossil. On Jul 25, 2014 6:18 PM, Joe Prostko joe.pros...@gmail.com wrote: Congratulations! I must say that Fossil is the best thing to happen to my development workflow this year, as I am pretty sure that using Git has resulted in the premature death of too many of my brain cells. I'm glad to be able to replace Git in every place that I possibly can with Fossil. The occasion of the seven year anniversary reminds me of something I've been meaning to ask on the list. It has been asked in the past according to my check of the archives, but is there any chance you would be willing to go on Floss Weekly and talk about Fossil? I know that you were on there to talk about SQLite quite some time ago, but I would love for there to be a show featuring Fossil. I know that Randal's current way for projects to get on the show is that he will only schedule a time if the project leader(s) contacts him directly. In any case, I hope you will consider going on the show (alone or with another core committer), as it would be a great way to let more people know about the awesomeness that is Fossil. - joe On Fri, Jul 25, 2014 at 11:57 AM, Richard Hipp d...@sqlite.org wrote: The seventh anniversary of the first self-commit of Fossil source code was this past Monday. Time flies. The logical predecessor of Fossil was CVSTrac (http://www.cvstrac.org/) which was a wiki and trouble-ticket system built atop CVS. CVSTrac became the inspiration for Trac (http://trac.edgewall.org/wiki/CvsTrac) which is a similar tool for SVN that became far more popular than CVSTrac and which is still in active use. Fossil was originally created to provide features needed in SQLite development, features that I couldn't get with CVS+CVSTrac, or with Monotone or Git or Mercurial or any other configuration management system available at the time. I worked on prototypes of Fossil for a year or more prior to the first self-commit on 2007-07-21, but none of those early prototypes survive. Code archeologists will be able to find a lot of commonality between the CVSTrac and Fossil source codes. There is a clear genetic relationship between the two systems. Fossil was created for the purpose of aiding in the development of SQLite. (Other uses for Fossil, though welcomed, are secondary.) The SQLite documentation sources ( http://www.sqlite.org/docsrc/timeline?a=2000-01-01) were split off from the SQLite source tree in CVS on 2007-11-12, just a few months after Fossil began self-hosting. But the core SQLite source code did not move to Fossil until 2009-08-11, just after the release of SQLite version 3.6.17, over two years after Fossil became self-hosting. The move from CVS to Fossil has proven to be a boon for SQLite development. CVSTrac was in active use by SQLite for a little over 7 years. To my knowledge, nobody uses CVSTrac any more. (OpenSSL was the last known user of CVSTrac and they switched over to Git at the beginning of 2013.) Fossil will soon overtake CVSTrac in terms of years of use, and Fossil has a great deal more momentum and a much larger user base than CVSTrac ever had. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
I'm on mobile device - please excuse typos/brevity. I managed a team of about 10 local committers (in my office) and about 10 more remote (across the country). I had a FreeBSD production environment. I setup a FreeBSD dev/testing environment where everybody was isolated by jails, and had their own personal full stack to work with. I encouraged (demanded) frequent commits and good commit messages. Many, many commits per day from each developer as they worked through their code. Each developer has their own named branch (typically their username/personal name) that they owned and they were responsible for. Developers were encouraged to talk amongst themselves and merge each others code where they were working on systems that touched each other. Devs used tags to mark their code as good when appropriate. To maintain the stability of their own branches, they were encouraged to use excursion branches where appropriate to isolate tricky work-in-progress. I maintained trunk. I merged individual tagged dev branches at least once a day, and worked out conflicts and stability with responsible devs when necessary. On successful integration, passing tests, I would tag the trunk commit and cut a release. By *far* the biggest issue was where developers did not commit small enough code changes, or merge other appropriate work frequently enough to keep from diverging. Without fail, too long of a period between merging appropriate code *into* their code, or tagging their code for merging into trunk meant headaches. Ironically, the single biggest disaster came from a collection of developers who worked for the company financing the project. Despite daily protests to tag their code for integration, for weeks they refused. Their work was ultimately pretty much unintegratable, prompting the company to send out one of their PMs across the country to fix our code. It was a joke, but I digress. Commit early. Commit often. Use branches and tags. Empower developers. Recipe for success. On Jul 26, 2014 7:53 AM, Eric Rubin-Smith eas@gmail.com wrote: I'm starting a company with some folks. Their notion of the default choice for SCM is git + JIRA for bug tracking + some other tool we'd pick for code review. This is probably quite common. Since the answers to my questions will probably be interesting to a relatively wide audience, I hope the forum will forgive the length of my post. By 'code review' here I mean a web-based tool that has a formalized state machine for (a) uploading code deltas (b) filing and fixing defects against the uploaded code and (c) having the right set of people sign off. Like Code Collaborator. I guess JIRA has an integrated tool that is free for small teams too. Whatever. It just needs to eventually support reviewing every line of code that gets written, in case we decide to go in that direction. I'm trying to convince my co-founders to use fossil. I won't address all of fossil's strengths, since you will all agree with me. I want you to give me some ammunition on the weaker points: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? * Code review! DRH has said on this forum (and I'm paraphrasing here) that he prefers to review humans more than code. If he decides he trusts the human, then he mostly trusts the human's output. So he didn't really care to write a native tool for code review for Fossil. This is what I think I need the most help with. While I feel mostly the same as DRH on the matter, I also would like to have a story in case one day the team decides they want to have every line go through a review process. If I don't have a story up front for that then it will be a biasing factor against Fossil, since it will be more likely we'd need to go through a transition (one they would worry is onerous or error-prone) to some other SCM in the future. I've come up with some work-flows that sort of simulate code reviews right from within fossil. For example, you might make each of your check-ins on its own branch, and when that check-in is accepted it gets merged into the feature branch. The existence of a pending review is signaled by a naming
Re: [fossil-users] Issue compiling with 16f1076334 and newer revisions
On Fri, Jul 25, 2014 at 11:08 PM, Joe Prostko joe.pros...@gmail.com wrote: Using the handy `fossil bisect`, I found that this revision is causing me problems while compiling Fossil from within Haiku. I did some more digging, and the problem seems to be that the assert.h included from within config.h is causing problems when sqlite3.c includes config.h due to _HAVE_SQLITE_CONFIG_H being defined. I did a dirty workaround of copying config.h to jpconfig.h, and then commenting out the include line for assert.h on line 55 of jpconfig.h. I then edited sqlite3.c to include jpconfig.h instead of config.h on line 7635. All other files that include config.h build just fine, as the only file that has problems with config.h in its original form is sqlite3.c. Things compile and run just fine when jpconfig.h is included by sqlite3.c instead of config.h. I played around a bit to try to get some sort of clever header guard in place, but ultimately it didn't work...or wasn't clever enough. ;) If somebody more familiar with all of the code has any ideas, that would be appreciated. I'm sure I'm overlooking something obvious to fix this, all without negatively affecting other platforms. I thought I could find the answer by looking at the SQLite codebase, but well, it generates its config.h during configure, and it looks nothing like the config.h included with Fossil, that's for sure. Also, in case it's useful, here's the assert.h that is used by Haiku. http://cgit.haiku-os.org/haiku/tree/headers/posix/assert.h I'll probably look at this all again tomorrow if nobody has any ideas, but wanted to share my latest findings. - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Richard Hipp wrote:
Is there a better story for moving between any two bug tracking
systems? Do there exist any two bug tracking systems in the world were
you can move from one to the other without having to write some scripts to
transform the data?
I can't tell whether you're asking rhetorically or in earnest. I
think rhetorically.
To which I reply that I make no claim that I am being fair. :-)
I just want to use fossil, and am looking for talking points to
convince others that the two points I initially enumerated are not
going to bite us.
Fossil can give you the ticket data as SQL. I think that is probably
about as portable as ticket data is going to get.
... says the top SQL expert between here and the Romulan Neutral Zone. :-)
From an information theoretic perspective, yes, all the data is
available. But that doesn't necessarily mean that it's easy for a poor
user, unfamiliar with both the Fossil database schema and the import
requirements of the target tool, to move the data between them.
You can use the fossil sql command to run .dump to get the ticket
content and then load that content into *any* SQL database (MySQL,
PostgreSQL, Oracle, SQL Server - name your poison) You will then have
to transform the schema into whatever your target system expects. But I
think that is always going to be the case, no?
I hope not. Microsoft Office products can import/export to/from
different formats. Lots of products know about the particular file
formats required by other specific products for the purposes of export.
Fossil *could* support export to JIRA+git in particular, for example, by
providing a tool that (a) exports to JIRA's supported JSON import format,
(b) collects the mapping from the fossil ticket IDs to the JIRA ticket
IDs, then (c) does a git export but massages the check-in comments
according to the data collected in (b).
Such a tool that is written and tested by the fossil devs would
obviously be preferable to whatever my sad little user-brain could
generate.
I make no claim that writing such a thing would be the best use of the
fossil devs' time -- again, just wondering what is out there.
We do low-ceremony code review on SQLite.
{snip}
We use more ceremony for testing.
{snip}
Thanks for sharing that, Richard.
--
Eric A. Rubin-Smith
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
