> [1] When I first came across Fossil (sqlite docs) it took me a while to
> figure out that there is a menu option "files" that only becomes visible
> after loging in. At first I thought that access to files was just not
> available. I guess this has been set up this way to prevent spiders
> requesting the entire project history to be served. Would it not be
> better to have the "files" option greyed out, or to show a page saying
> "you must be (anonymously) logged in to view files"? This refers mostly
> to public repositories as local "fossil ui" access automatically does
> the login.
I agree with this. In this case I prefer disabled links over hidden links.
> [2] On the "files" page, one by default gets the union of all files
> checked in across branches and over time. I found this confusing, I
> would have thought that the default would be a view of the tip of the
> trunk. When first confronted with a project, trying to assess its
> structure, stuff now looks much more complex than it really is.
> Depending on the situation I would want a different view: tip of the
> trunk at first, tip of my personal branch later and the union view when
> deeply involved in the project. Perhaps this should be a config option,
> or perhaps the default "files" view should have a second menu line, with
> various view options; the view option should be "sticky" with the last
> view chosen within a single ui session. Related to this, would it not
> make sense to add a zip link to the files page, for any view other than
> the union view ?
I'm coming to similar conclusions. It seems to me that the Leaves page
improved with some additional links about those Leaves. For example something
like this:
[3275d9c63c] [files] [zip] [timeline] Leaf update makefile for win32 (user:
rwilson, tags: trunk)
Where the [files] link would take you to a page with all the files on the tip
of that leaf, i.e. the same files that would be in the zip download.
Also, I think the files page could benefit from a submenu that toggles between
'tip' and 'union all'.
> [3] On first use, the menu immediately requires an understanding of the
> concepts of leaves, branches and timelines. A first encounter with
> Fossil will often be via cursory browsing of a public repository and
> also by folks not very much into distributed version control. In my
> opinion it would be good to add a "help" item to the menu that leads to
> a wiki page with a "getting started" level explaination of the various
> menu options and what they are for. This should perhaps be configurable
> (i.e. showing the "help" item is a user attribute: "show" for nobody and
> anonymous and "hide" for all others) in order not to gum up the UI when
> its usefullness is gone.
I'm happy with the Wiki link in this regard. It is easy enough for people to
add their own help link on the Home page, but a default help.wiki that shipped
with all new repositories would be nice.
> [4] Is the order of main menu options currently the most
> helpful/insightful? Perhaps the ordering
> Home/Branches/Files/Tickets/Leaves/Tags/Timeline/Wiki/Login is more
> logical ?? First you look at a project's description via Home, then at
> its source via Files, next you have a look at ticket history. Only then
> you start working with leaves, etc. Is "Wiki" the best name for this
> option? Isn't the wiki mainly accessed via "Home" and the "Wiki" menu
> used for access to "Wiki Admin"? I don't like that latter label ("Wiki
> Admin") either so perhaps somebody has a better suggestion.
I'm happy with the menu for the most part; I'm mainly worried that enhancements
will bloat the main menu. I think more use of submenus may be in order.
> [5] On the branches page, shouldn't "trunk" receive a special position,
> i.e. always at the top of the list?
I wish the branches were sorted by date of most recent leaf; though perhaps a
submenu toggle would be in order here 'sort alpha', 'sort date' - though the
'timeline' submenu adequately does the same thing. I agree that the trunk
should have some prominence.
I do like that the closed branches are separated out. One thing that bothers
me, and correct me if I'm wrong, but I think that the only way to close a
branch is to merge it into another branch. Sometimes you just want to obsolete
a branch or declare it inactive.
> I did like the idea of a "Download" menu option for public repositories
> at first glance, as passers-by would expect to find such an option. To
> such folks, Fossil appears to be something like sourceforge and alike.
> However, I don't see the point of such a menu option in non-public
> repositories. Hence I think now that it is perhaps not such a good idea.
>
> Paul
Ron Wilson, Engineering Project Lead
(o) 434.455.6453, (m) 434.851.1612, www.harris.com
HARRIS CORPORATION | RF Communications Division
assuredcommunications(tm)
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
