Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 27 July 2014 11:04, Eric Rubin-Smith eas@gmail.com wrote: 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). I'd find a tool like that really useful. I'd find the reverse even more useful. I look forward to your F/OSSed implementation! More seriously, you're comparing a small project like Fossil's with the capabilities of behemoths like Microsoft. Microsoft can throw as many code monkeys at something as they'd like, hence the wide variety of exporting formats (of wildly varying stability and utility) in Microsoft Office, et al. In a small F/OSS project it's going to be more tools created by people who scratched an itch and shared their ointment. (OK, maybe I stretched that analogy a bit far.) I don't think you're going to find the tool you're looking for. What you might find useful, however, is Marc Simpson's fsl wrapper which will allow you to almost seamlessly integrate whatever tools you do come up with into Fossil's command line and workflow: http://fossil.0branch.com/fsl. Be sure to check out the cookbook for ideas of how to accomplish things as well: http://fossil.0branch.com/fsl/wiki?name=Cookbook. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
More seriously, you're comparing a small project like Fossil's with the capabilities of behemoths like Microsoft. No, I'm really not. drh was making a claim that users will ALWAYS have to convert between two database schemas when exporting tickets from one system to another. He was making a technical claim, and I was disagreeing with it by analogizing the situation to other situations in which export is useful and in which a product knows about the accepted import formats of other products. I could just as easily have said that there is this cool little gem of a DVCS called fossil. The devs know about Git of course so they wrote a Git-specific export tool. I don't need to know what fossil's schema is, nor the import format of git, to use the tool. I don't think you're going to find the tool you're looking for. Okay, 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] 'finfo' missing contents; 'finfo --brief' ok
2014-07-23 12:37 GMT+02:00 Michai Ramakers: Hello, seems 'fossil finfo' is missing output: Fixed here: http://fossil-scm.org/index.html/info/dcb6076572 Thanks for reporting this! Regards, Jan Nijtmans ___ 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] Issue compiling with 16f1076334 and newer revisions
2014-07-26 5:08 GMT+02:00 Joe Prostko joe.pros...@gmail.com: Using the handy `fossil bisect`, I found that this revision is causing me problems while compiling Fossil from within Haiku. Should be fixed here: http://fossil-scm.org/index.html/info/14aea4f883 Thanks for the report. The real issue was that although SQLite is supposed to be compiled with NDEBUG=1, this macro was defined too late, after the inclusion of the first assert.h. This resulted in the TESTONLY macro to be an empty define, but the assert() macro was not empty. On most platforms (e.g. linux) the assert() macro is re-defined every time when assert.h is included again, then this problem is not noticed. However, it really was a problem in fossil's build system, which caused fossil's embedded SQLite to be compiled in debug mode :-( This side-effect was not intentional! Regards, Jan Nijtmans ___ 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] Issue compiling with 16f1076334 and newer revisions
On Sun, Jul 27, 2014 at 3:22 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-07-26 5:08 GMT+02:00 Joe Prostko joe.pros...@gmail.com: Using the handy `fossil bisect`, I found that this revision is causing me problems while compiling Fossil from within Haiku. Should be fixed here: http://fossil-scm.org/index.html/info/14aea4f883 Thanks for the report. Confirmed as fixed on Haiku, and compiles/works fine on this Manjaro machine as well. Thank you! The real issue was that although SQLite is supposed to be compiled with NDEBUG=1, this macro was defined too late, after the inclusion of the first assert.h. This resulted in the TESTONLY macro to be an empty define, but the assert() macro was not empty. On most platforms (e.g. linux) the assert() macro is re-defined every time when assert.h is included again, then this problem is not noticed. However, it really was a problem in fossil's build system, which caused fossil's embedded SQLite to be compiled in debug mode :-( This side-effect was not intentional! I had honed in on the problem being related to NDEBUG, but didn't get any farther than that. I am glad you were able to figure this out, and that the fix helped to address a Fossil bug as well. :) - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New [globalState] TH1 command (globalStateCmd branch)...
I'm seeking feedback on the new [globalState] TH1 command, which is currently available on the globalStateCmd branch. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Suggestion for cloning
When cloning a repository, if I don't have write privileges, can autosync by default be set to pullonly in the clone, to prevent annoying pull only - not authorized to push? Maybe this should be the default always, even if I have write permission, in order to prevent accidental pushes? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] commits not seen on 2nd local worktree unless forcing initial commit
2014-07-22 11:35 GMT+02:00 Michai Ramakers m.ramak...@gmail.com: Hello, while toying around with Andy Bradford's fix/analysis, found something else, which seems related to the no-initial-commit feature which is recent default in trunk. This indeed looks like a newly-found corner-case which doesn't behave as intuitively expected. Proposed fix here: http://fossil-scm.org/index.html/info/0d8cb8e30a (I'm not sure yet it's completely covered with this, I'll do some more testing...) Thanks! Regards, Jan Nijtmans ___ 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] 'finfo' missing contents; 'finfo --brief' ok
On 27 July 2014 20:35, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-07-23 12:37 GMT+02:00 Michai Ramakers: Hello, seems 'fossil finfo' is missing output: Fixed here: http://fossil-scm.org/index.html/info/dcb6076572 thanks for the fix, seems to work fine. 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] commits not seen on 2nd local worktree unless forcing initial commit
On 27 July 2014 22:58, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-07-22 11:35 GMT+02:00 Michai Ramakers m.ramak...@gmail.com: Hello, while toying around with Andy Bradford's fix/analysis, found something else, which seems related to the no-initial-commit feature which is recent default in trunk. This indeed looks like a newly-found corner-case which doesn't behave as intuitively expected. Proposed fix here: http://fossil-scm.org/index.html/info/0d8cb8e30a (I'm not sure yet it's completely covered with this, I'll do some more testing...) and thanks for this fix as well - original test works fine here, now. I'll continue running this branch here until it's merged (although I don't make new repos too often). And I'd be interested to do more testing if pointed in a direction - although I guess that's difficult to do (the pointing). 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] commits not seen on 2nd local worktree unless forcing initial commit
2014-07-27 23:45 GMT+02:00 Michai Ramakers: and thanks for this fix as well - original test works fine here, now. Merged to trunk now. Thanks for your feedback! I'll continue running this branch here until it's merged (although I don't make new repos too often). And I'd be interested to do more testing if pointed in a direction - although I guess that's difficult to do (the pointing). Don't know, I'm out of ideas for possible more corner-cases. Regards, Jan Nijtmans ___ 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: 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 am familiar with with 2 code review tools that are web based. Reviewboard is pretty much exactly what you describe. It is written in Python and comes with a set of scripts for importing diffs from various VCSs. One of those scripts would need to be copied and modified to support Fossil. The other is Kiln (from Fog Creek). It is actually a front-end for Hg. I mention it because Fossil already provides some of the functionality Kiln adds to Hg. Kiln's code review capability requires that change sets be committed to branches. It displays diffs and accepts comments from reviewers. Fossil already can display diffs in a suitable form via its web UI. Review comments could be supported with Fossil tickets, using some combination of custom fields, TH1 and JavaScript. My team does use Fossil tickets for code reviews. We have not done what I just described above. We just append any review comments to the ticket requesting the review. This works for us. * Export of tickets. The only ticket export format my team uses, well, the Project Manager uses, is CSV to put the tickets into spreadsheets, since (a) that is what higher level managers want reports in. And (b) the PM finds it easier to use spreadsheets during meetings. * Code review! (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? I don't know if what I described that my team does for code reviews meets your needs, but it works for us. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
