On 5 October 2014 12:41, Stephan Beal <sgb...@googlemail.com> wrote:
> On Sun, Oct 5, 2014 at 5:05 PM, David Mason <dma...@ryerson.ca> wrote:
> Gotta love users who provide patches :).
:-)
>> + if ( statusFlag ) fossil_exit(nUpdate==0);
>> }
>
> As you mention, there "might" be legacy issues pending there, but if there
> are, none of them are immediately obvious to me.
The only thing that occurred to me was that (without the switch) a
"nothing-to-do" run would have the same exit status as some fatal
situation and someone somewhere might be dependent on fossil non-zero
exit status implying some significant error. But as you say, it seems
unlikely.
> It still seems horribly inefficient, though, considering all the db-level
> work it does there, knowing it's going to roll back the transaction.
Except that only happens in the case where it's going to do some real
work when I call it without the -n, versus Andy's suggested shell
version that does a lot of work every 5 minutes. So I think this is
the right trade-off. Also all that work is in-memory, is it not?
And, with this running every 5 minutes, any change in the repo is
likely to be from a single commit, so not that much changing.
> Another option comes to mind which would, i think, provide a one-call
> solution and might avoid major surgery: the ability to squelch output at the
> app level, such that fossil_print() and friends become no-ops when called
> when the squelch flag is set.
Unless I'm missing something, this is to make a true -q option, right?
I thought of this, but wasn't certain that all output was via
fossil_print and fossil_fatal. Also for my case, redirecting output
to /dev/null is perfectly reasonable.
> Care to take a crack at such a patch? The major funcs which would need a
> check for the flag are fossil_print() and (if error messages should also be
> hidden) fossil_fatal().
Sure, I could do that... but not likely until tomorrow.
Continuing to think about it, my issue is that I don't want to send
empty emails, an a look at mail(1) suggests that:
fossil update -m | mail -E -s "some subject" m...@he.re
would do exactly what I want if the -m switch suppressed all output
unless it was actually doing something, since the -E switch on email
suppresses the mail if the body is empty.
This has the advantage that update is only called once, so there's no
wasted DB work that needs to get undone, doesn't change the output
status, or require any additional shell scripting or for the server to
be running.
So how about that? Andy?
Thanks for the discussion... I think I've finally come to the cleanest
solution. Sometimes we (I) need to forget about our possible
solutions and remember what the real requirement is.
../Dave
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
