On Aug 4, 2018, at 12:13 PM, Gilles <codecompl...@free.fr> wrote:
>
> But then, "fossil changes" returns nothing either, and it's coherent with the
> Unix philosophy.
Precisely. You’re applying Windows mores to a tool that comes out of the Unix
tradition. As long as you do that, you’ll have expectation mismatches.
It is not correct to say that Fossil had no output in this case. Its output
was the exit status code, which was zero, meaning there was no failure. Since
there is also no standard output, that means there are no differences. You can
check for this combination in a POSIX shell:
diffs=$(fossil diff)
if [ $? = 0 ]
then
echo No difference found.
elif [ -n "$diffs" ]
then
echo Difference found.
else
echo Program exit failure, code $?.
fi
If you know the history of mathematics, you know what kind of contortions they
had to go through before they invented the concept of zero. This is analogous.
If we relied instead on text output to signal “No changes,” it would break if
Fossil was ever localized:
if fossil diff | grep -q 'No changes'
then
… do something for the change case …
else
… do something else for the no-change case …
fi
You’d erroneously end up in the no-change case because the output would be
“Aucun changement” on an OS configured for a French locale, if Fossil ever gets
localized for French.
If you doubt the usefulness of such a script, consider a “make release” script,
which first checks whether there are any changes to unexpected files before
proceeding. In one of my projects, the only expected changes upon creating a
release are a new section in the ChangeLog.md file and a single-line change to
the VERSION variable within the Makefile; anything else means you’ve probably
forgotten to check something in separately first. The above shell script logic
allows us to test for things like this and stop the process if pilot error is
suspected.
If I’ve yet to convince you that this design philosophy is sensible, consider
that it’s one of several reasons why Unix type systems are far more easily
scripted than Windows systems, which in turn is one of the largest reasons
they’ve taken over the cloud space. You can’t deploy 1000 Windows instances at
peak load every day and tear them back down as the load decreases when you
cannot easily and reliably script the process.
I speak from experience. One of my current Windows software projects drives a
program that is externally scriptable only by programming to its .NET API. If
this program were available on Linux and followed its conventions, I’d expect
to be able to replace the .NET code and its attendant MSI deployment mess with
a far simpler shell script. I’ve probably spent more time getting the MSI
creator working than I’d have spent writing that shell script.
Incidentally, I asked you for “fossil stat” output in part because I
anticipated this possibility: it didn’t give you an “EDITED” line for these
files you’ve been checking for changes. You will come to notice absences like
that. It will be a clue that you either have no changes or that you forgot to
add a new file to the repository, so Fossil is still ignoring it.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
