On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp <d...@sqlite.org> wrote:
On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff
<veedeeh...@googlemail.com>wrote:
hi there,
a modest suggestion:
I would prefer (and I believe it actually would be more correct, thought
what's "correct" is always arguable)
if `fossil set' would explicitly report not only explicitly set (local)
and (global) parameters but also the
default values (whose values I tend to only partly memorize...). so
filling in all the "empty" fields a la
autosync (default) on
would be better, I believe. any opinions on that?
I don't know about the user interface, but I've been thinking for a long
time that the internal C APIs for settings need to be fixed to make use
of
a single global table of default values, rather than depending each
setting
query to specify the default value.
I understand that you are maybe more concerned about the software
engineering
aspect and if I get the meaning of your mail right: yes that would be
better.
but switching back to a simple user perspective: why not report the
default settings
(at least optionally: I realize that the `fsl set' report would no longer
allow to
easily identify the (few?) explicit settings if all defaults are reported
but I'm not sure
if that really would be an issue)?
some more remarks from a new user:
I've been trying out fossil only for the last two weeks or so. and coming
from `mercurial'
(and knowing `subversion' to some extent) I find the user interface quite
idiosyncratic in places (such an impression was not caused when first
using mercurial, e.g.):
-- the sparse `fossil set' output I've mentioned already.
-- `fossil stat, changes, info, extras': of course, there is no
requirement to mimic `hg', `svn' or what else but
the "signal to noise" ratio for the average user is quite low in my view.
`stat' and `info' seem
to differ only by the mostly irrelvant `project-name' entry while both
reporting full lenghts
SHA1 codes which mostly seem not to be needed here (well, I did not, up to
now...).
mostly I would like to get information here whether there are changes
(edits, adds, removals...) or not and what files are not tracked.
`hg stat' does provide that. in fossil I have to do `fossil changes' _and_
`fossil extras'.
-- there seems no easy way to get a list of ignored files (as per the `fsl
set ignore-glob' setting.
in most cases I find that this setting should be part of the "global
state" of the project. in `hg'
there is a default file `.hgignore' where the glob patterns can be put. I
find this most useful since
in this way the ignore patterns can (but need not) be made part of the
project state that is transfered
to the "other" side.
-- fossil timeline: I find this really hard to read and use for at least
two reasons:
* the forced line breaks in the commit messages: would it not be better
to let the terminal to line wrapping if need be? than I could keep the
commit messages mostly on a single line
if I prefer this by increasing the terminal width.
* updating/merging etc. requires leading unique (at least 4) characters
from the SHA1 hashes. the `hg' approach to allow (of course only locally
vaild) incremental revision numbers as an alternative is much nicer in my
view.
-- the `fossil diff --from rev1 --to rev2' syntax deviates from the much
more common (and easier to type `-r rev1:rev2') for no good reason I can
see.
-- the command line parser needs some getting used to and seems to have
some quirks. e.g., commands accept unique abbreviations as being valid,
but options do not.
at least `fossil timeline -showfiles' does not: `fossil time -show'
does nothing...). there are some more over which I stumbled but I don't
recall right now
(except that spaces are enforced even after short options but again:
matter of taste).
-- rather frequent typos in the help pages (reports of those are desirable
or not?)
-- the transfer statistics stuff reported at every checkin. usually I
don't want to see this. maybe this should be made configurable (or is it
already?) in the UI.
I'd like to emphazise: this sure is not a complaint but just expression of
my opinion that the UI (and in turn adoption of `fossil') might profit
from some changes.
and I'd like to learn what the community thinks of these issues. are all
of them irrelavant?
j.
regards,
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
______________________________**_________________
fossil-users mailing list
fossil-users@lists.fossil-scm.**org <fossil-users@lists.fossil-scm.org>
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
