Hi fellow fossil users,
I'm sorry for such too long an email. Let me give you a short index
of it, so you could skip the rest if you are not interested in what
I'd like to talk about:
* description of my work processes
* small-scale
* large-scale
* suggestions on what could be improved to make Fossil easier to use for me
* color support
* changelists
* grep
* log
* linear history
* relative revisions
* single-revision diff
* show revision
* combined repository and checkout databases
* web server - hyperlinks to wiki syntax
Besides writing this too long a note on "what could be done", I also
spent some time thinking over the syntax of some of the proposed
commands and extensions. If there is enough interest to that, I'm
going to follow up this topic and share those ideas too.
Cheers,
Nikita
== Workflows ==
I have been using fossil for quite some time to take care of my pet
projects at home, and I can say it suits good enough for that sort of
projects, although there is a way to improve it.
At work I use both git and svn and I would like to give Fossil a try
too, but it lacks some features I really depend on in my day-to-day
work. I tried to summarize what I need from SCM for my work on
work-scale projects and what could be done to make Fossil fit that
niche better. I hope I am not the only one who would make use of
those changes, for projects of different size, be it a small project,
a big one or something in the middle.
Well, being a sole project developer of a pet project, I do not care
about many things that matter a lot for larger scale projects. A home
project is usually not a big one, there is only one developer (me).
Most of the time I do not have much independent activity happening at
the same time, I more or less remember _what_ were my changes and,
roughly, _when_ I worked on one thing or another. Project history is
mostly linear, sometimes I do have branches, but that is not a common
case. I rarely need to look into project history, but I always want
to review the change before I commit.
Typical use cases for home project work is:
* do a piece of work I intended to finish today
* review the change to make sure there are no typos, all temporary
debugging code is cleaned, and so on
* commit
At work, my projects are much bigger - from hundreds to several
thousand files, in numerous directories. People make anywhere between
10 and 200 commits to the repository every day, and my use cases,
surely, are quite different.
I usually work on several branches (checked out into different
directories) during the day, switching between them. Usually, there
are several other people working on each branch; branches lifespan is
several weeks long, and they get updated from the trunk a few times
during their lifetime. Use cases are also more diverse and
complicated:
* preparing the change (more or less the same)
* analyzing code during development, for example:
* looking into history - who changed the file I am working on and
what was done to it
* looking for a string in files managed by the SCM
* if I found an interface or a function introduced by someone else
that I could use too, I would want to look at that commit and get a
broader overlook of that code
* analyzing code during merge to trunk or update from trunk. I
sometimes need to check out one of the branches being merged to
analyze both directories. I usually want to find who, when and why:
* changed a particular file of interest
* changed a line in the file
When I found that change, I need to know what was changed in the
same commit besides the file. I also often want to see what was the
full content of file before the change
* analyzing code during bug fixing. As there are many people working
on different features, bugs are often caused by someone else's
changes, I need to find what was committed, for what reason, look into
a ticket and so on.
As I said, usually there is too much happening in the repository in
general, and there is no much reason to look into overall activity.
Usually, I take a glance on overall activity once or twice a day. If
I get interested in any particular change and related topic, I would
always look into linear history from that change to the beginning of
time or to the first commit of that branch. If I found a merge point
that brought the change, I would go analyze merged-in branch the same
way.
For these use cases, I could identify several items not implemented in
Fossil itself. Some of them are actually implemented in the built-in
web interface, but, being mostly a console user, I look at fossil from
that angle. Also, some of them (e.g. coloring the output) are
available through third-party tools, but as fossil is posisioned as a
self-sufficient SCM, they should be baked in.
== color support - review the change, history analysis ==
One should not underestimate the significance of color on terminals
these days, that's why both git and mercurial and a lot of tools have
color support in their base distribution. It makes it much easier to
spot the changes in a diff, to group similar files together in a
status report at a glance or to scan a timeline, immediately
separating commit messages from a list of modified files. Sure, there
are exceptions from every rule, and there are people used to
monochrome output, so there should be a way to disable color or tune
it to one's needs.
== change sets - preparing the change ==
I often end up having several sets of unrelated changes. For example,
one set is my temporary change to the build system to disable some
things to make build process faster, but these changes are not
intended to come into the end product and are not to be committed.
The other set is the change I want to commit. Working with git, I use
staging area to collect the needed changes and group them together,
but subversion really shines here with its changelists. svn cl syntax
is inconsistent, but I root for the idea to label connected files for
the commit/review purpose and I would love to have something like that
in Fossil
== grep - development support ==
Often the projects building process leaves many temporary files in the
working directory. I could grep over the directory using standard
grep but then I have to filter out those temporary files created by my
build system. Git grep is an answer to this problem. By the way,
grep support is already in the official Fossil roadmap.
== combined log - history ananlysis ==
The most unusual thing about Fossil is that it does not have "log"
command. There are two different commands to access file history -
timeline and finfo, but all other systems use log command to access
history of both files and directories, be it the root directory of the
project or a subdirectory. In Fossil, there is no easy command line
way to get the history of a subtree.
I believe that most users are used to that universal log command and I
would be surprised if fossil's timeline/finfo duo is not _the_ most
thing people struggle with in the beginning of their relationship with
Fossil. Ticket d1b50f4d06579e43c24d0e35f9d28d9562e95126 is the
perfect example of this.
== linear history - history analysis ==
The other thing is that Fossil, like cvs, but unlike svn or git, shows
global history, including changes committed to branches parallel to
the currently checked out one. That is fine for small or medium
projects, and sometimes for large ones too - to get an overview of a
project - but for most of my day work I want history to be more usual
- history of just my branch and all its immediate ancestors following
main merge parents. I don't need to see what happens in parallel
branches. At least there should be an option to get this kind of
history.
== relative revisions - history analysis ==
In Fossil there is no way to refer to a parent of a revision, with the
exception the parent of checked out revision. svn has numeric
revisions, (N-1 works fine to refer to the state of a file or a branch
before commit N), but hash-based systems have to use something else
instead. git uses ^ and ~{n}, mercurial has "relative" numbers to go
back in history and also has an extension to use git ^ suffix. I
would like to have git syntax in Fossil.
== diff for a revision - history analysis ==
I often use "svn diff -c rev" and "git show rev" to show a single
commit as a whole. Until recent Andy Bradford's change introducing
--checkin option, the only way to achieve that in Fossil was to use
"fossil diff --from parent_rev --to that_rev".
== show - history analysis ==
I like "git show" and "svn log --diff" as they give me all information
about commit I need - commit message, metadata and full change of the
commit. I would be happy if Fossil had "show" command to display all
that information. Web UI has it:
http://localhost:8080/ci/e1c2bd2680cf6412?sbs=0
It would be even better if show were universal. By "universal" I mean
that, ideally, it should work the same way for a tree change, file
change, wiki, ticket and so on.
See also ticket 10c0c8f65ca24a9f183eb2d6b7f24cdbb5cc192a
== "checkout as repository" ==
When you come from svn or git, the very first question is "why do I
need to _open_ the repository I've just cloned?". Repository database
as a separate entity is definitely could be useful in some cases. For
example, I might have a repository on a flash drive and share it
between several computers, as a makeshift synchronization tool. The
other use case could be a large project with several active checkouts:
I would like to have checkouts of several branches of the same
projects without extra overhead for repository data.
On the other hand, most of the time I hardly use that at all - all my
own repositories are located on my NAS and served over http. Each of
computers I use has at most one checkout of each repo. The same is
true for external fossil projects - I have one checkout, and, if I
need to, I switch between branches using fossil update. In that case,
separation of repository and checkout data feels an added complexity.
I ran into this concept criticism more than once, for example, there
is a ticket for that: 7e5f093a231d88cbea06c81b073fd99786187d49
== wiki syntax ==
One of the weaknesses of the web interface is wiki syntax. After you
chose markup format and click "Create", you have to keep formatting
rules in mind. There is no quick help showing basic formatting rules
and there are no links to markdown or fossil wiki syntax pages. I
would appreciate a lot if there were links to the official wiki_rules
and md_rules files.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
