On Tue, 20 Nov 2012 01:13:51 +0100, Richard Hipp <[email protected]> wrote:
On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff
<[email protected]>wrote:
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.):
Constructive feedback is always appreciated. Thank you!
User feedback is enormously important, and I do pay close attention to
it.
And Fossil has been greatly improved as a result of user feedback.
Perhaps
the most striking example of this is the change graph on the web timeline
that was suggested by Andreas Kupries - I probably would not have thought
of that on my own, and yet now I don't see how I ever survived without
it.
That said, please also recognize that I wrote Fossil because the other
VCSes out there (or that were out there 7 years ago) did not meet my
needs. And so one should not expect Fossil to be just like all the
others. Fossil works how I want a VCS to work. If you find Fossil
useful
as well, that's cool tool, and I am happy to make reasonable
accommodations
for differing tastes. Even so, one should not expect Fossil to be like
every other DVCS. That would defeat the purpose, no?
sure right and that's definitely not my attitude.
-- 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...).
"stat" is (mostly) a combination of "changes" and "info".
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'.
That would not work well with my workflows, since I tend to keep lots of
extraneous unmanaged files laying around, and I do not use ignore-glob.
well, I do heavily so.
So
it would never occur to me to have a command that shows both changes to
managed files and lists unmanaged files, all at the same time. In my
check-outs, such a command is likely to drown the user in a list of
unmanaged files that is so huge that it obscures the changes to managed
files.
on the contrary I find this very useful from my experience with `hg':
first thing I do when putting some dir/procject under revision control, is
set up the "ignore-glob" list (e.g. "*.o" or
all the auxiliary files generated by `pdflatex'). than I do `fossil add .'.
if in the course of the project new files are created but I forget to
explicitely
`add' them I do get a notification from `hg stat', listing untracked (not
the ignored!),
added, removed, modified files. from this list it's easy to decide whether
untracked
files have to be `add'ed or whether the ignore-glob pattern has to be
extended.
so, in a workflow where one _does_ make extended use of ignore-glob, such
a listing will
never be long. it only will be (as in your case, if, e.g. the *.o files
are simply untracked,
but not ignored. I hope you can see my point. since such a listing
obiously collides
with your own workflow: how about a "long" or "comprehensive" option for
`changes' (which seems
the neares equivalent to `hg stat') to make it put out the combined list
of changed (!) tracked
files and (not-ignored!) untracked files?
Maybe we could invent a system whereby a user could create their own
fossil
commands to suite their own tastes? So you could define a site-specific
"fossil stat" command that simply runs "changes" and "extras" in
succession. Would that help?
yes, I would something like that. this approach indeed works very well in
`hg' in my view.
(potential problems with overriding intrinsic commands have been
mentionend in this thread
already, but should be manageable in my view).
-- 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:
I seldom use "fossil timeline", preferring instead to run "fossil ui" and
look at the timeline with the graph in my web-browser. Am I the only one
that thinks this way?
I am sure you are not the only one leaning the GUI, especially under
windows (no offense meant...), but
I find the command line much more effective 99% of the time. if one could
add
the DAG (optionally) as `ascii art' to the timeline output I probably would
leave the webbrowser alone completely (but I admit using a graphical
diff/merge tool ;-))
* 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.
I tend to use symbolic names. Ex: "fossil up trunk; fossil merge
experimental;"
I find myself rather frequently do diffs of incoming changes from other
people
against the baseline version being *CURRENT* before the `fossil up'. these
incremental changes _never_ have tags, so I have to rely on the revision
IDs.
-- 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.
You think that "-r rev1:rev2" is more intuitive than "--from rev1 --to
rev2"? Really? If it's important, we could add it as alternative
syntax,
I suppose. But what would you do if the name of rev1 contained an
embedded
colon? Do we have to invent some kind of escape syntax to accompany this
notation?
someone else essentially already said it all: not intuitive but it's
really standard with many
VCSs and (more important to me) less typing.
-- 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?)
Typo reports are desirable.
OK, will start to prepare a list...
-- 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.
We can consider an option to control this.
yes, that would be nice. especially with `ssh' (now that it works so
nicely) I
still flinch at the "killed by signal 2" message (which I of course
understand,
but it always somehow initially looks like something failed). if it "just
works"
I'm usually happy with just getting told how many (and possibly which)
files
have been modified during the sync (i.e. essentially the very bottom of
the current
report).
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
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
