Re: [fossil-users] comparison with Git
On Oct 9, 2012, at 20:44 , Eric wrote: On Tue, 9 Oct 2012 12:19:59 +0200, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: But who would prevent a cow worker from using them? Cow worker Reference to the Dilbert comics... The idea is that, especially in corporate environments, you'll at some point end up working with people who'll be, in your eyes, highly defective. Unless you're always in exclusive control of hiring, you'd better think of mechanical ways to enforce your vision of the project. Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Actually there are two kinds of people in the world, those who expect something to do whatever they think it should, and those who look at what it is designed to do, and how it is designed to be used, and then either use it accordingly or find something else. Of course success in extending or embedding depends on the level of available skill in awk or Perl or Expect or whatever. Remember that the target end-user for Fossil is a developer! Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations into various IDE's, GUI front-ends and other integrations are so popular. I may be OK with CLI, but it already bit me a few times: I can not use Fossil in my day job, because there's no Eclipse plugin (apart from that, the team said whatever, we're free to start new projects in whatever VCS that Eclipse supports). But don't say it's easy to extend by writing a separate client or ipc-ing to this one... Why not, it's a perfectly acceptable technique. Acceptable, yes, in some circumstances. But compare: open3 a process and parse the output (is it even guaranteed to be stable?) to a function call... Kind regards, Remigiusz Modrzejewski ___ 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] Seg fault when doing 'fossil http'
Richard Hipp wrote:
[...]
Worked ok here. What version of fossil do you have? What does fossil
version tell you?
I'm on Debian, and am seeing it both the current release:
This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC
...and from the upcoming release:
This is fossil version 1.23 [d3512db100] 2012-08-19 12:09:31 UTC
...and I've tried tip from the repo and it's there too.
I've tracked it down. From cmd_http():
if( g.argc!=2 g.argc!=3 g.argc!=6 ){
fossil_fatal(no repository specified);
}
g.fullHttpReply = 1;
if( g.argc==6 ){
g.httpIn = fossil_fopen(g.argv[3], rb);
g.httpOut = fossil_fopen(g.argv[4], wb);
zIpAddr = g.argv[5];
}else{
g.httpIn = stdin;
g.httpOut = stdout;
zIpAddr = 0;
}
fossil_fatal() tries to write an error message to g.httpOut, which of
course hasn't been set up yet, and so ends up doing fprintf(NULL, ...).
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car. --- Scott Adams
___
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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Actually there are two kinds of people in the world, those who expect something to do whatever they think it should, and those who look at what it is designed to do, and how it is designed to be used, and then either use it accordingly or find something else. Of course success in extending or embedding depends on the level of available skill in awk or Perl or Expect or whatever. Remember that the target end-user for Fossil is a developer! Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations into various IDE's, GUI front-ends and other integrations are so popular. I may be OK with CLI, but it already bit me a few times: I can not use Fossil in my day job, because there's no Eclipse plugin (apart from that, the team said whatever, we're free to start new projects in whatever VCS that Eclipse supports). Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. The mercurial folks have a Python API, but strongly recommend that you just run hg, as they work to keep that compatible between versions, and make no such effort with the Python API. It seems to have a plugin for most GUI IDEs. But don't say it's easy to extend by writing a separate client or ipc-ing to this one... Why not, it's a perfectly acceptable technique. Acceptable, yes, in some circumstances. In *far* more circumstances than linking to a library is acceptable. But compare: open3 a process and parse the output (is it even guaranteed to be stable?) to a function call... Well, an API - no matter how it's implemented - is only as stable as the developers make it. Whether or not you break an API when you upgrade the provider depends *far* more on the developers than whether they chose to provide it via an executable or a shared library. And if you're going to compare them, compare the entire process: One is - well, open the executable and parse the output. The other is: select a language that can be coerced into linking with the library you want to use, write or find a wrapper if it's required that will translate between calling conventions and data types, load the shared library and wrapper code, and *now* you can call your wrapper to get and convert the data. Oh, and if you want to let someone else use your plugin, you have to make sure all the licenses involved are compatible. Nuts, after writing the Python wrapper for the perforce C++ library, I wound up rewriting it for our Windows group to use the p4 command instead of the library, because that was easier cheaper than buying the C++ compiler used to build the Perforce Windows binary and porting Python to it. But it made our support scripts portable across Windows and Unix. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] comparison with Git
On Oct 10, 2012, at 14:28 , Mike Meyer wrote: Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. But Fossil is not GPL. It would make perfect sense to link it wherever you'd like. For Git, it seems that it's primary implementation is a bit too messy for most big projects, so they simply reimplement it. Eclipse's implementation is called JGit. And it does provide a reasonably stable Java API, used by a few projects. On the other hand, Fossil's implementation is (apart from the regular forking) quite nice. I'd bet you a beer that once the JSON API is finished (in my already outlined understanding), it will be used by some useful projects. Kind regards, Remigiusz Modrzejewski ___ 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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Oct 10, 2012, at 14:28 , Mike Meyer wrote: Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. But Fossil is not GPL. It would make perfect sense to link it wherever you'd like. For Git, it seems that it's primary implementation is a bit too messy for most big projects, so they simply reimplement it. Eclipse's implementation is called JGit. And it does provide a reasonably stable Java API, used by a few projects. Yeah, the *reimplimented* git in order to avoid the language and license issues of using the git code directly. That pretty much kills the argument that having to invoke fossil as a command is to much work! On the other hand, Fossil's implementation is (apart from the regular forking) quite nice. I'd bet you a beer that once the JSON API is finished (in my already outlined understanding), it will be used by some useful projects. No bet, because I agree with you. Except that I consider using modern concurrency technics a plus, not a minus. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
