2015-08-30 10:27 GMT+02:00 Stephan Beal <sgb...@googlemail.com>: > 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. >
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
