On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin < baptiste.darous...@gmail.com> 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. > 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. -- ----- 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
