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? > > -- 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. 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. 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? > > -- 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? > * 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;" > > -- 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? > > -- 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. > > -- 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. > > > 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 >>> [email protected].****org <[email protected]** >>> scm.org <[email protected]>> >>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/** >>> **fossil-users<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/ > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
