Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Martin,


Thank you for pointing that out, I somehow missed -p option.

It seems "fossil timeline parents current -p " is somewhat verbose 
equivalent of what I expected from "fossil log ", with the 
exception of treating merges


Thank you,
Nikita

On 11/01/2016 06:14 AM, Martin Gagnon wrote:

On Tue, Nov 01, 2016 at 01:08:47AM -0400, Ron W wrote:

At the risk of wading in to a minefield, I have some thoughts.
On Fri, Oct 21, 2016 at 2:14 PM,
<[1]fossil-users-requ...@lists.fossil-scm.org> wrote:

  From: Nikita Borodikhin <[2]elit...@gmail.com>
  Date: Fri, 21 Oct 2016 16:02:33 +

  == combined log - history ananlysis ==

  The most unusual thing about Fossil is that it does not have "log"
  command.  [...]  In Fossil, there is no easy command line way to get
  the history of a subtree.

Fossil already have this, like at the "-p" option of the timeline
command.

   $ fossil timeline -p subdir/
  or
   $ fossil timeline -p .


   




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Steen Hoyer]

Thank you Martin for pointing out the timeline -p option, and thanks to 
the participants in this thread! Somehow I had overlooked both the -p 
option and the chng=GLOBLIST option for the web ui timeline---I am very 
happy to find them now!


Somewhat related: the previously described feature I find myself wishing 
for most is subtree slice checkouts (aka 'narrow clones'), for the first 
reason (checkouts from deep in a hierarchy) described here: 
http://stackoverflow.com/a/3215625


   Steen


On 2016-11-01 8:14 AM, Martin Gagnon wrote:

   $ fossil timeline -p subdir/
  or
   $ fossil timeline -p .


   



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Martin Gagnon]

On Tue, Nov 01, 2016 at 01:08:47AM -0400, Ron W wrote:
>At the risk of wading in to a minefield, I have some thoughts.
>On Fri, Oct 21, 2016 at 2:14 PM,
><[1]fossil-users-requ...@lists.fossil-scm.org> wrote:
> 
>  From: Nikita Borodikhin <[2]elit...@gmail.com>
>  Date: Fri, 21 Oct 2016 16:02:33 +
> 
>  == combined log - history ananlysis ==
> 
>  The most unusual thing about Fossil is that it does not have "log"
>  command.  [...]  In Fossil, there is no easy command line way to get
>  the history of a subtree.

Fossil already have this, like at the "-p" option of the timeline
command.

  $ fossil timeline -p subdir/
 or
  $ fossil timeline -p .


  


-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Ron W]

At the risk of wading in to a minefield, I have some thoughts.

On Fri, Oct 21, 2016 at 2:14 PM, 
wrote:
>
> From: Nikita Borodikhin 
> Date: Fri, 21 Oct 2016 16:02:33 +
>
> == combined log - history ananlysis ==
>
> The most unusual thing about Fossil is that it does not have "log" command.  
> [...]  In Fossil, there is no easy command line way to get the history of a 
> subtree.
>
>
Other than:
fossil finfo path/to/dir/*

I don't know what history of a subtree would be. Fossil tracks files, not
directories

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.
>
>
Never bothered me. I rarely use finfo, I suspect this may have been the
case in the early days of Fossil, with finfo being added as a separate
command, perhaps to avoid issues with the parsing of the existing timeline
command.

If someone were inclined enough to implement a new log command that could
show either commit history or file history, the constraints of the existing
timeline command could be avoided.


> == 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.
>
>
Once in a while, being able to specify a revision relative to another would
be handy.

While git's ^ suffix is simple, tag+n or tag-n would be more flexible.

== show - history analysis ==
>
> I like "git show" and "svn log --diff" as they give me all information about 
> commit I need ...
> 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.
>
>
I don't really miss this command, as it is very easy to just use the web UI
to see the differences.

But, I can see where a "fossil show" command could be handy as finfo isn't
really a variant of info for files.

== "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?".  ...
> Each of computers I use has at most one checkout of each repo.
>
>
Coming from SVN, "fossil open" was basically the same as "svn checkout"
with a different name. (I'd prefer "fossil checkout" be an alias of "fossil
open", but in Fossil it has a different function.)

The few times I have setup a local "slave" SVN repository I still had to do
"svn checkout" to create a working copy. (SVN is not a distributed VCS, so
you must commit directly to the one repository. "Slave repositories" were
introduced as a way to have a local, read-only copy of the repository, but
commits still have to go first to the "main" repo, then the slaves have to
pull from the main.)

So doing "fossil open" after doing "fossil clone" (or "fossil new") was
nothing strange or new to me.

Perhaps adding a "--open" option to the "fossil clone" and "fossil new"
commands would be a reasonable enhancement to Fossil. (I think this
approach would be cleaner than having Fossil try to guess what you are
asking it to do.)

"git clone" was weird to me at first. Also I very much used SVN's ability
to have multiple working copies checked out from a single repository. With
git I have to clone the repository to get additional working copies. And
then I have to push/pull changes between them.

== 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.  
> ...  I would appreciate a lot if there were links to the official wiki_rules 
> and md_rules files.
>
>
This can be added by editing the header and/or footer (Admin->Skins->Header
or ->Footer). It is possible to conditionally display links based on the
page being displayed (and/or other factors).

Perhaps someone could update the default "skin" for the Fossil UI to
include a wiki help link.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[K. Fossil user]

Hi,

>« Be concrete: how do you want tags to work which makes them entirely 
>different from branches? »

I've said that tags and branches are the same technically speaking.
However, for people those are not the same : for example the master branch is a 
special branch.

When in git you do :

git clone some-url

The code downloaded is the latest one, from the master branch (HEAD most of the 
time).

>« Why is it a problem that Fossil branches are implemented in terms of 
>auto-propagating tags? »

Marketing issue that you obviously don't know about.You can talk about release 
(tags) but not about experimental code (branch).

>« Branches vs tags have nothing to do with “marketing.” »

In the Fossil perspective, I agree with you, in the user perspective who knows 
nothing about Fossil/git/etc. that counts.
No one would like to read something like :
"Download the branch A because it [what you may want] is there" 

>« Both options exist because both have a reason to exist »

Which means they are different ? :D
People don't want to have multiple branches if they just would like to clone 
the repository or, if they want to have a special release (tags).
>« I challenge you to show me a real use case where Fossil’s write locking 
>causes an actual concurrency problem »

No one would show you that because as I've said, few people use Fossil.
May be a researcher could do that just for you.

>« My contention is that you will get zero measurable improvement in Fossil 
>performance when doing such a thing, which if true proves that SQLite is not 
>the problem here »

That is a point of view nothing serious. Citation needed as you asked... to me.

>« If you have to artificially generate 1000 simultaneous checkins to show that 
>system A is better than system B, that proves nothing, since virtually no 
>project has checkin rates anywhere near that level. »

a) Github is widely used ... many simultaneous access and so on.

b) When it comes to millions my assumption is that git can do the trick : 
Fossil will never.
 e.g. When you will use a 360 software (whatever it is), you need a rock solid 
DVCS.

>« Even large projects generally have only dozens of checkins *per day*, which 
>means that any given time, there is only zero or one checkin happening, which 
>in turn means concurrency IS NOT A PROBLEM. »

So your perspective is for some few guys when mine is for a more general 
purpose which is the future...
In another word, concurrency matters for Fossil.

>« A poll may feed information into the marketing process, but market research 
>is not marketing itself »

As I've said, Poll is marketing, but as I understand what you've said, I should 
be precise ?
When you need a poll it is because after some research you may have noticed 
that you need people point of view.
For example a guy asked someone to test/check is code...
When you check and give YOUR results to the guy, you explain to the guy what is 
good or not.

You do marketing because some projects don't ask anything and don't want any 
interactions : finally, they are in trouble.
(who would like to use your product if no one could complain to you ? And there 
are other ones around ?)

I never said that Poll is ONLY marketing, I've said that it is a tool for 
marketing.
Marketing is a vague word that even expert won't agree with when it comes to 
definition. So who are we to think that we've got a definition, and to be 
clear, who are you when you send to use a definition of marketing ?
Isn't it an evidence that you don't know what marketing is ?

>« Notice that there is no discussion of communication, responding to user 
>complaints and requests, or triaging bug reports. »

People don't talk about communication because this is not what they are coming 
for MOST of the time.
Clever people understand why communication (a marketing part) is so important.
Unless for you google teams are stupid when they use Stack (MatterMost is a 
clone sort of stack) ?

to sum up what I've said:
a) Poll is one of the numerous tools to do marketing.
b) Fossil is not good at concurrency/large projects which are bad things for 
the future.
c) Nowadays, few people uses a DVCS, but in the future when it comes to a 360 
software (Saas etc.) then a good DVCS is one of the key for success.

Definition of Marketing that could be accepted :
« Marketing is the activity, set of institutions, and processes for creating, 
communicating, delivering, and exchanging offerings that have value for 
customers, clients, partners, and society at large »

Marketing - Wikipedia
https://en.wikipedia.org/wiki/Marketing
« The holistic marketing concept looks at marketing as a complex activity and 
acknowledges that everything matters in marketing »




Best Regards

K.

  De : Warren Young 

*snip*
You know it’s time for a thread to die when we have to resort to the dictionary 
for rebuttals, but since this is likely to be my last reply to this thread, 
this might as well be the cap on it:
 

Re: [fossil-users] features I'd like to have in fossil

[Joerg Sonnenberger]

On Mon, Oct 24, 2016 at 10:35:46AM -0600, Warren Young wrote:
> As far as I can tell, syncing to a remote repository locks the entire
> remote repository, making it *worse* than Fossil, not better.  (SQLite
> concurrency locks only single tables, not the whole database, and then
> only for writes, not reads.)  

If you use WAL mode, you can have a single writer locking the whole
database for the transaction, but pure readers can continue fine. I
would have to check how this interacts with the temporary tables needed
by the xfer code for pulls, e.g. whether pulls need a write transaction
or not.

The only scalability issue on the hosting side I really hit more than a
couple of times is related to certain Chinese spiders following every
link they can and ignoring robots.txt. That's an issue for any version
control system though. I can assure you that repository hosting is the
smallest issue, even for very large repositories.

I have some old presentations still online talking about the NetBSD
repository and the fossil conversion, that's likely still one of the
biggest fossil repositories around:
http://www.sonnenberger.org/archive/presentations/fossil/
http://www.sonnenberger.org/archive/presentations/fossil2/
(content mostly the same, from 2011)

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Warren Young]

On Oct 22, 2016, at 5:55 PM, K. Fossil user  
wrote:
> 
> >« Branches in Fossil are just auto-propagating tags »
> This is what they've said, technically at least.
> For me this is not how I want it to be, because for most people tags are not 
> branches 

Be concrete: how do you want tags to work which makes them entirely different 
from branches?

Why is it a problem that Fossil branches are implemented in terms of 
auto-propagating tags?

> (Marketing again).

You keep misusing that word.  Please take it as a fact from a native English 
speaker.

Branches vs tags have nothing to do with “marketing.”

> In another word, why am I using branches when as I've said tags suffice ?

Both options exist because both have a reason to exist.  I use both, each for 
very different purposes.

> >« your typical Fossil server simply doesn’t have all that much concurrency 
> >going on.»
> That is why I used to say that Git is better for big projects.

I tried Googling to find out what Git’s concurrency model is, and got almost 
nothing useful.

As far as I can tell, syncing to a remote repository locks the entire remote 
repository, making it *worse* than Fossil, not better.  (SQLite concurrency 
locks only single tables, not the whole database, and then only for writes, not 
reads.)  

If you simply mean that Git operates the way Fossil does with autosync turned 
off, and thus each checkin doesn’t take resources on the central server, I’ll 
give you that.  But again, I challenge you to show me a real use case where 
Fossil’s write locking causes an actual concurrency problem.

> >« If you feel I’m wrong, go port Fossil to Oracle or whatever, and then 
> >we’ll see if it’s gotten faster. I think it’ll get slower, but you go and 
> >prove me wrong »
> Oracle no. Another one will go faster if it is in a cluster.

I’m completely missing your point, then.

I understood your original complaint to be that Fossil’s use of SQLite is bad 
for concurrency, so I proposed that you port it to an Oracle DBMS, which has 
row-level locking, which would solve that objection.

My contention is that you will get zero measurable improvement in Fossil 
performance when doing such a thing, which if true proves that SQLite is not 
the problem here.

I’m not pushing Oracle specifically here.  I make the same prediction for 
MySQL, MariaDB, Microsoft SQL Server, DB2, and PostgreSQL, all of which also do 
row-level locking.

I’m talking about real-world use cases here, not benchmarks.  If you have to 
artificially generate 1000 simultaneous checkins to show that system A is 
better than system B, that proves nothing, since virtually no project has 
checkin rates anywhere near that level.

Even large projects generally have only dozens of checkins *per day*, which 
means that any given time, there is only zero or one checkin happening, which 
in turn means concurrency IS NOT A PROBLEM.

> >Server loads that I've talked about...
> Server loads will be higher if there are too many access (too many people too 
> many changes at the same time for example): and Fossil is a web server.

The sqlite.org web site is served by Fossil.  It seems pretty fast to me, 
despite the high number of hits it must serve every day.

> too many access is not a big deal for git. :-D

[citation needed]

> >« Who did say that? »
> a) People said that poll is not needed, in another word we don't need 
> marketing at all…

Again you misuse that word.  Polls are not “marketing.”  A poll may feed 
information into the marketing process, but market research is not marketing 
itself.

Anyway, proper scientific polling is seriously hard to do right.  Just putting 
a poll on a web site is nearly useless from a scientific standpoint.  (Look up 
“self-selection bias” if you don’t know why.)

> b) Answering [...] feature set IS marketing, to be clear it IS communication.
> Communication IS a set/portion/part of marketing.

You know it’s time for a thread to die when we have to resort to the dictionary 
for rebuttals, but since this is likely to be my last reply to this thread, 
this might as well be the cap on it:

  https://www.wordnik.com/words/marketing

Notice that there is no discussion of communication, responding to user 
complaints and requests, or triaging bug reports.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi,


On 10/22/2016 12:27 AM, Nikita Borodikhin wrote:

== 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.

Can you give examples of why you’d need to do this?  I mean, what’s wrong with 
“fossil up 1234abcd” between each diff?  Is the problem simply that it changes 
working directory contents?  I don’t mean to trivialize that if so, I just want 
to be clear on what you see as the problem.

The Fossil web UI has a semi-hidden feature to do this.  Just click two bubbles 
in the timeline and you get a diff page showing the changes between those two 
versions.


Reviewing the history of changes in a branch.  Sometimes when you're 
looking into history of a file, what you need is to go into the 
history one commit at a time.  After you found the last revision of 
the branch, you can check three commits without having to copy three 
revision hashes:

git show sha1
git show sha1^
git show sha1^^

UI does not need this, because you point to the revision visually.


Sometimes it is hard to remember what is the actual use case because you 
use the features very organically.


I just realized my use case for this feature is a bit different. I often 
use it analyzing one file and trying to recover what it looked like some 
time ago.  Even more specific, how its part looked like back then, and 
how it evolved.  I came up with the sequence of commands to go through 
"history of file part backward":


 * git annotate  (annotated file is opened in pager)
 * scroll it to the place I am interested in
 * copy revision number (one or several cases I use mouse in terminal)
 * close pager
 * git annotate file ^
 * scroll pager to that place

I do the same with svn, but for svn, instead of "^", I subtract one from 
the copied revision number.



Nikita
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Richard Hipp]

On 10/22/16, Nikita Borodikhin  wrote:
>
> What I expected from this post is, well, to share my problems with the
> community.  There was a chance I could get a discussion on the problems
> to better understand what people think and whether they find it
> important or not.  That could help me to set the right priority to my work.

And your input is greatly appreciated.  Thank you for contributing.
I'm sure your ideas will have at least some influence on future
directions.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[K. Fossil user]

Hi,

>« This is "fossil-users" mailing list, and it exists to share opinions,
problems, issues, suggestions and so on, would you agree to that? »

Exactly my tought.

>« learning curve »

I've said something about that.

>« The less people use it
- the less new ideas, less improvements and evolution »

Unfortunately you are right.

>« I do not propose any breaking changes »

Not me either.

>« What I expected from this post is, well, to share my problems with the
community. There was a chance I could get a discussion on the problems
to better understand what people think and whether they find it
important or not. That could help me to set the right priority to my work. »

Agreed !
I may add that I am here to help Fossil : this does _not_ mean that I would let 
people say something wrong about me or what I've said or think.

Again, Fossil needs to do/improve marketing.



Best Regards

K.


  De : Nikita Borodikhin 

*snip*
Hi Richie,
*snip*
   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Richie,


On 10/22/2016 06:40 AM, Richie Adler wrote:



* suggestions on what could be improved to make Fossil easier to use for me

As a mere reader of the list, I have to ask: why should *the Fossil team*
consider this important?

You haven't presented any compelling reason to change significatively the way
Fossil operates, besides that it would be nice for you.

Am I missing something?


This is "fossil-users" mailing list, and it exists to share opinions, 
problems, issues, suggestions and so on, would you agree to that?



Well, I shared some my problems and I proposed solutions I saw in other 
projects for those problems.  I am far from assuming that I am 
exceptional, so I have to assume that there are other people who have 
the same problems and who would benefit from the changes.  Some of the 
issues are caused by differences between fossil and other systems, big 
enough to make learning curve too steep for my taste.  The steeper the 
curve - the less new people would adopt fossil.  The less people use it 
- the less new ideas, less improvements and evolution.



By the way, I do not propose any breaking changes.  I propose adding new 
concepts and commands and improve the way existing ones work, but those 
are all non-critical changes.  The only thing that needs careful 
consideration is "combined databases", but it also could be implemented 
without losing compatibility.



I do not expect anyone working on a free project to do anything for me.  
I do not even expect any review or criticism, for that matter.  No work 
to share - no feedback, right?  I would want to have my problems solved 
though, and I am going to work and implement my proposals myself and 
_then_ get review from people. If then people say "no way, we do not 
need this in Fossil" - that's fine, that's how open project works.  I'll 
keep my changes in my local repository.



What I expected from this post is, well, to share my problems with the 
community.  There was a chance I could get a discussion on the problems 
to better understand what people think and whether they find it 
important or not.  That could help me to set the right priority to my work.



Nikita



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Richie Adler]

> * suggestions on what could be improved to make Fossil easier to use for me

As a mere reader of the list, I have to ask: why should *the Fossil team*
consider this important?

You haven't presented any compelling reason to change significatively the way
Fossil operates, besides that it would be nice for you.

Am I missing something?

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[K. Fossil user]

Hi,
I don't have much time now but I just answer to what you've said :
No I don't ask Fossil team to switch now over MatterMost.I ask them to think 
about it. I remind you that I am not the owner of the Fossil.
It is not because I ask it for the Best of Fossil that it would mean that I do 
want that myself.

And for the record, I don't want to use Mattermost with Fossil as an 
IM/Chat/communication-thing-you-may-think.E-mail suffice.  
Best Regards

K.

  De : Warren Young <w...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Samedi 22 octobre 2016 3h08
 Objet : Re: [fossil-users] features I'd like to have in fossil
   
Yes, and the impression I got is that the thing you are most concerned with is 
switching the community over to MatterMost.

Personally, the exact method the community communicates is one of the least 
important parts of Fossil.  I’d far rather time and effort be spent on Fossil 
itself rather than on chasing the IM/chat/email alternative of the month.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Color support should be customizable and should have global off switch.

Not only color blindness is the issue, but also people have all sort of 
background colors on their terminals.  Around me, I see black, gray, 
white, green and blue backgrounds.



On 10/22/2016 12:35 AM, Scott Robison wrote:


> If you color lines by meaing, it is easier to understand:

Unless you're color blind, in which case it might be impossible to 
understand.




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Scott Robison]

> If you color lines by meaing, it is easier to understand:

Unless you're color blind, in which case it might be impossible to
understand.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Warren,


On 10/21/2016 11:14 AM, Warren Young wrote:

On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin  wrote:

== 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

For diff, simply install colordiff, which is almost certainly already packaged 
for your OS.  Then:

 $ fossil set diff-command 'coloridff -wu'
 $ fossil diff -r 2016-10-01 | less


to group similar files together in a status report at a glance

Define “similar.”  Do you just mean that all the modified files should group 
together separate from the added files and such, or something different?

This is one of the areas where working code will speak louder than well-crafted 
prose.

Let's suppose I have some changes to fossil:

$ fossil status
EDITED src/bisect.c
MISSINGsrc/blob.c
EDITED src/comformat.c
ADDED  src/configuration.c
MISSINGsrc/configure.c
EDITED src/content.c



If you color lines by meaing, it is easier to understand:


$ fossil status
EDITED src/bisect.c
*MISSINGsrc/blob.c*
EDITED src/comformat.c
ADDED  src/configuration.c
MISSINGsrc/configure.c
EDITED src/content.c





== change sets - preparing the change ==

I often end up having several sets of unrelated changes.

You admitted to not using branches, apparently because you don’t see the point 
of them in a single-developer project.  This is one good use for them.

That is, if you’re working on one feature and then see that you’ve gone off on 
a  tangent and are now building something unrelated, you can check the first 
feature’s unfinished changes into a branch, then return to the trunk to work on 
the second feature.

You’re using branches in this case to stash unfinished work without breaking 
the trunk or admixing unrelated features in a single checkin.
I can use branches for that, that's true.  There is also another use 
case - changes are not directly related to each other and are logically 
separated, but I have to have both of them until I finish the work.  
E.g. Makefile changes to dramatically speed up the build on my machine.





Working with git, I use staging area to collect the needed changes and group 
them together

I think the git staging area fights against team cohesiveness, primarily 
serving the needs of the sort of developer who likes to go off and hide in 
their office, not showing their work to their team members until it’s 
“perfect.”  Committing publicly, early, and often is objectively better, a fact 
that falls naturally out of the mathematics of control theory.

I realize that this is not a problem for you, but I’d guess that more Fossil 
users are on teams than not.
Anyway, before the commit, you have to make sure you're committing what 
you want, and you review your changes before the commit, right?  Staging 
area in git is the instrument created exactly for what I'm taking about 
- to help developer to prepare the commit and separate what he's going 
to commit from what he's not going to commit.


How much time it takes - minutes, hours, or weeks - is up to developer.  
Every instrument can be perused, you can hit nails with a microscope, 
but it is not intended to be used that way.





subversion really shines here with its changelists

Some months ago, a proposal was made that I consider vastly superior to svn 
change lists: a flag for the stash command that would let you select and reject 
each hunk of the current diff interactively.

If you had three essentially unrelated changes in the current working copy, you 
could stash all the hunks belonging to two of them, then test the third change 
separately and check it in once you’re happy.  Then you could “stash pop” and 
repeat to polish the other two, one at a time.

It is important that this not be implemented in terms of checkin, since you 
need to test each unrelated feature separately before checking it in.


I missed that proposal, but it must looks more like hg record than svn 
changelists.  If that is the case, it is more granular, but in the way 
it becomes a completely different tool.  It just works on too a 
different level.





== 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.

The solution to that is ag, The Silver Searcher:

   http://geoff.greer.fm/ag/

If you’re looking for a project, it would be nice if someone would teach ag 
about Fossil ignore rules.  It already knows about git, hg, and svn.  
Meanwhile, we have its built-in .agignore feature.

ag is awesome in many other ways.  In addition to being much faster than grep 
and with a shorter typical 

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Andy,


On 10/21/2016 12:53 PM, Andy Bradford wrote:

Thus said Nikita Borodikhin on Fri, 21 Oct 2016 16:02:33 -:


== 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.

You  could simply  open a  new checkout  and keep  unrelated changes  in
different checkouts of your repository. For example,

fossil new /tmp/test.fossil
mkdir /tmp/tinker && cd /tmp/tinker && fossil open /tmp/test.fossil
mkdir /tmp/explore && cd /tmp/explore && fossil open /tmp/test.fossil
mkdir /tmp/maybe && cd /tmp/maybe && fossil open /tmp/test.fossil

Etc...


The problem is that quite often these two sets are: changes I want to 
commit (when they are ready), and changes I do not want to commit, but I 
have to have in my working copy until I commit the first set.


Changelists help me to separate them and refer to each set by name, 
rather than by naming each file every time I need to do something - get 
status, check diff and so on.



For example, let's suppose I work on a bug.  I have some local changes 
to Makefile to, say, disable some components to speed up the build.  I 
want to have have those changes in my checkout even after I'm done with 
the bug.  I also have some changes in state_machine.c to make bug to 
appear every time I start the program.  I do not want to commit it, but 
I do not need to keep it after I'm done:



$ fossil cl add build Makefile
$ fossil cl add tmp state_machine.c
$ fossil cl add bug300 state1.c state2.c
$ fossil status
--- Changelist build
EDITED Makefile
--- Changelist tmp
EDITED state_machine.c
--- Changelist bug300
EDITED state1.c
EDITED state2.c
$ fossil diff --cl bug300
$ ...
hack-hack-hack
...
$ fossil status
$ fossil add bug300 state3.c
$...
hack-hack-hack
...
$ fossil status
--- Changelist build
EDITED Makefile
--- Changelist tmp
EDITED state_machine.c
--- Changelist bug300
EDITED state1.c
EDITED state2.c
EDITED state3.c
$ fossil diff --cl bug300
$ fossil commit --cl bug300
$ fossil revert --cl tmp


Working on the change I am about to commit, I can easily end up having 
10 or 20+ files, if I have to, say, refactor an interface, add extra 
parameter to a widely used function and so on.





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

By  ``label connected  files'' I  assume  you mean  related changes.  If
you're already doing the above  suggestion, there's always the option to
stash the changes.


That's true, I could stash changes, but that is not best solution. 
Without change lists, I can not visually separate my temporary changes 
when I look at status output.  And when I check the diff, I do not want 
my to see my temporary changes.  Here changelists really help because of 
the name you give to that group of files.  Compare

$fossil diff --cl bug300

to

$fossil diff state1.c state2.c state3.c


Nikita
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

Hi Warren,


On 10/21/2016 07:21 PM, Warren Young wrote:

On Oct 21, 2016, at 7:31 PM, Nikita Borodikhin  wrote:

I would like to be able to commit only needed changes:

So say:

$ fossil ci Makefile state_machine.c

It’s actually less typing than defining a changelist and then committing the 
changelist.

If you’re not certain about the changes in those two files, you can “fossil 
diff” just those two files:

   $ fossil diff Makefile state_machine.c | less

Then edit the command from history to change “diff” to “ci” when you’re 
satisfied.


The difference here is that I define _name_ for the _group of files_ 
upfront.  I can do some iterations of change-check_status-view_diff 
before I commit the change, and it helps me a lot to see my files 
grouped in the output of status.  Again, example I had is very simple, 
but imaging I have twenty files changed because of renamed interface.


When I look at status output, I can check two parts: my change set, to 
make sure it does not have anything unneeded, and the rest of it, to 
make sure it does not have any of my changed files missing from the 
changelist.  Without changelists - well, it is possible, but it less 
convenient (you have to list files every time you do something) and more 
error-prone.



Here’s the alternative with branches:
 $ fossil ci --branch my-new-feature state1.c
 $ fossil up trunk
 $ fossil ci --branch my-other-new-feature state2.c
 $ fossil up trunk
 $ fossil ci

It’s a bit more complex, but has a different effect, so you can’t compare them 
apples-to-apples.  Here, we’re saying that state1.c and state2.c contain 
partially finished features which we want to set aside so that we can focus on 
Makefile and state_machine.c.  Maybe we’ll make more changes before checking 
the changes in.

You can use the stash instead if you don’t like branches:

 $ fossil stash save state1.c
 $ fossil stash save state2.c# yes, separate commands!
 $ fossil ci

It’s simpler in that you don’t have to keep returning to trunk to revert the 
changes, but if you’re working on a team, now you have the Guy In the Room 
Problem:

 https://www.youtube.com/watch?v=oY6BCHqEbyc

If you’re not working on a team, the main disadvantage of the stash over 
branches is that it’s local to a particular open checkout, so that if you’re 
working on multiple machines or have multiple checkouts, you can’t simply 
switch branches to see your in-progress feature, you have to somehow copy the 
files over manually.

Another problem with the stash is that if you say “fossil close,” it will offer 
to throw away your stash, which is irrecoverable if you accept.  At least with 
branches, you have a copy of the code durably archived.

There’s no shame in having partially-working code checked in on a branch.  
Broken code on the trunk is a problem for many reasons, but it’s quite common 
to make many checkins on a branch to bring the initial checkin on that branch 
into shape suitable for merging back into the trunk.


I like and use branches, but they do not solve the problem changelists 
solve.  The problem is: I often have two sets of changes in my local 
checkout.  One set is supposed to go into branch and, eventually, into 
trunk, and the other set consists of my local changes to help me work on 
that piece of code.  That other set should not get into repository.  I 
could have committed it and undo that commit before the merge back to 
trunk, but sometimes I would forget to do that.


I have that problem that often, so I wrote a wrapper that demands 
specifying changelist to svn commit.



Changelists help me to:
* isolate those groups of files
* work with groups using names of the group rather than files one by one
* evolve the group alongside with my work, adding files into it, until 
change set is ready to be committed




Nikita
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Nikita Borodikhin]

The thing is I have to have both changes locally in order to fix the
problem, but I do not want to commit some of them.  Let me give you an
example.

Let's imagine I work on some embedded project.  I have a device my project
is targetted to, and I have a development board based on a slightly
different model.  Working on fixing some bug in the project, not really
affected by those MCU differences, I changed my Makefile to default to my
development board and I also changed a startup file to make that bug happen
every time I reset the MCU.

$ fossil status
...
EDITED Makefile
EDITED state1.c
EDITED state2.c
EDITED state_machine.c

Here, Makefile and state_machine have my local changes, needed while I am
working on that bug.  I would like to see that in the output of status and
I would like to be able to commit only needed changes:

$ fossil cl add build Makefile
$ fossil cl add tmp state_machine.c
$ fossil cl add bug300 state1.c state2.c
$ fossil status
...
--- Changelist build
EDITED Makefile
--- Changelist tmp
EDITED state_machine.c
--- Changelist bug300
EDITED state1.c
EDITED state2.c
$ fossil commit --cl bug300
$ fossil revert --cl tmp

After I'm done, I still want to have Makefile change, as I am going to
continue to work on the project on the same development board.

Sure, this example is a little bit too simple, but you get the idea.
Unfortunately, it could not be stopped easily with branhces.

Cheers,
Nikita


On Fri, Oct 21, 2016 at 12:53 PM Andy Bradford <
amb-sendok-1479671619.hiacmifddnkpomfcb...@bradfords.org> wrote:

> Thus said Nikita Borodikhin on Fri, 21 Oct 2016 16:02:33 -:
>
> > == 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.
>
> You  could simply  open a  new checkout  and keep  unrelated changes  in
> different checkouts of your repository. For example,
>
> fossil new /tmp/test.fossil
> mkdir /tmp/tinker && cd /tmp/tinker && fossil open /tmp/test.fossil
> mkdir /tmp/explore && cd /tmp/explore && fossil open /tmp/test.fossil
> mkdir /tmp/maybe && cd /tmp/maybe && fossil open /tmp/test.fossil
>
> Etc...
>
> > 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
>
> By  ``label connected  files'' I  assume  you mean  related changes.  If
> you're already doing the above  suggestion, there's always the option to
> stash the changes.
>
> Andy
> --
> TAI64 timestamp: 4000580a7267
>
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Warren Young]

On Oct 21, 2016, at 5:57 PM, K. Fossil user  
wrote:
> 
> However, I was astonished by what a community manager answered to another guy.

You say that like you think I hold some kind of official title.  I’m just 
another Fossil user, like you.  When I used that term in the other thread, it 
was all-lowercase.  Like you, I also don’t contribute much code to Fossil, so I 
also don’t have much say in how the project runs.

When I give you my opinions about Fossil and the Fossil project, it is from 
that perspective.

> > « You admitted to not using branches, apparently because you don’t see the 
> > point of them in a single-developer project »
> 
> As a community manager if you said that to another guy, it means that he 
> should use branch even if he doesn't want to.

I think one should use Fossil on its own terms, not try to treat it like Git, 
yes.

I think the same way about all technology.  When I write Perl code, I try not 
to write it in C++ style, and when I use Cygwin, I don’t get too upset when it 
imperfectly emulates Linux.

Compatibility, interoperability and the Principle of Least Surprise are all 
good things, but sometimes you just have to learn a new way of doing things in 
order to work most efficiently.

> For example, I don't want to use branch but I prefer tags even if branch is 
> better. Tags have nothing to do with branches of course !

Branches in Fossil are just auto-propagating tags.  Under the hood they’re very 
nearly the same thing, which is why you can use them mostly interchangeably in 
Fossil commands.

> a) It is said that SQLite is not good at concurrency. Thanks God someone, not 
> me, dare to say that SQLite is not good when it comes to concurrency !

I think you mean me as that “someone,” but I was just telling you something 
that DRH pointed out much earlier:

  https://www.sqlite.org/whentouse.html

And the only reason I pointed this “flaw” of SQLite out is the point out that 
for Fossil, the problem doesn’t matter, because your typical Fossil server 
simply doesn’t have all that much concurrency going on.

If you feel I’m wrong, go port Fossil to Oracle or whatever, and then we’ll see 
if it’s gotten faster.  I think it’ll get slower, but you go and prove me wrong.

> b) It creates higher server loads that should not occur.

According to who?

And what does this have to do with my application of control theory to software 
project management?

> c) it creates too much information so the Fossil file would grow too much for 
> no serious reasons.

My largest Fossil repo is currently running at a 39:1 compression ratio.  I 
think that’s fairly awesome.  So again, [citation needed].

If you’re referring to the fact that Fossil doesn’t diff-compress 
pre-compressed binary blobs (e.g. JPEGs), point me at a DVCS that does.

> Who said that marketing (e.g. poll, good communication, etc) is not needed in 
> the Fossil realm ?

I don’t know.  Who did say that?

What *I* said is that answering user questions, triaging feature requests, and 
improving the Fossil feature set is not “marketing.”  Marketing is an entirely 
different set of activities, which may also improve the standing of Fossil in 
the marketplace, but by different means.

> PS: Have you read my unmet needs Warren ?

Yes, and the impression I got is that the thing you are most concerned with is 
switching the community over to MatterMost.

Personally, the exact method the community communicates is one of the least 
important parts of Fossil.  I’d far rather time and effort be spent on Fossil 
itself rather than on chasing the IM/chat/email alternative of the month.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[K. Fossil user]

Hi again,
Most of the time I try not to interact with people discuss.
However, I was astonished by what a community manager answered to another guy.
So I decided to give my opinion about it.

> « You admitted to not using branches, apparently because you don’t see the 
> point of them in a single-developer project »

As a community manager if you said that to another guy, it means that he should 
use branch even if he doesn't want to.
For example, I don't want to use branch but I prefer tags even if branch is 
better. Tags have nothing to do with branches of course !
I just don't want branches because I prefer that all the stuffs are in ONE 
branch (Master, trunk, head, whatever-you-call-it).
Of course, I've never said that using a branch is bad : if one said he doesn't 
want, it's up to him.

>« Committing publicly, early, and often is objectively better, a fact that 
>falls naturally out of the mathematics of control theory. »

Nope.
a) It is said that SQLite is not good at concurrency. Thanks God someone, not 
me, dare to say that SQLite is not good when it comes to concurrency !
b) It creates higher server loads that should not occur.
c) it creates too much information so the Fossil file would grow too much for 
no serious reasons.
d) I even guess that it may create merge issues if everyone works with the same 
trunk and the same file (rare).

Who said that marketing (e.g. poll, good communication, etc) is not needed in 
the Fossil realm ?

As you could all guess, I prefer not to read all the rest.I expect that some 
people may read it and then give appropriate responses ...

Best Regards

K.PS: Have you read my unmet needs Warren ?

  De : Warren Young <w...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 21 octobre 2016 18h14
 Objet : Re: [fossil-users] features I'd like to have in fossil
   
On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin <elit...@gmail.com> wrote:
> 
> == 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

For diff, simply install colordiff, which is almost certainly already packaged 
for your OS.  Then:

    $ fossil set diff-command 'coloridff -wu'
    $ fossil diff -r 2016-10-01 | less

> to group similar files together in a status report at a glance

Define “similar.”  Do you just mean that all the modified files should group 
together separate from the added files and such, or something different?

This is one of the areas where working code will speak louder than well-crafted 
prose.

> == change sets - preparing the change ==
> 
> I often end up having several sets of unrelated changes.

You admitted to not using branches, apparently because you don’t see the point 
of them in a single-developer project.  This is one good use for them.

That is, if you’re working on one feature and then see that you’ve gone off on 
a  tangent and are now building something unrelated, you can check the first 
feature’s unfinished changes into a branch, then return to the trunk to work on 
the second feature.

You’re using branches in this case to stash unfinished work without breaking 
the trunk or admixing unrelated features in a single checkin.

> Working with git, I use staging area to collect the needed changes and group 
> them together

I think the git staging area fights against team cohesiveness, primarily 
serving the needs of the sort of developer who likes to go off and hide in 
their office, not showing their work to their team members until it’s 
“perfect.”  Committing publicly, early, and often is objectively better, a fact 
that falls naturally out of the mathematics of control theory.

I realize that this is not a problem for you, but I’d guess that more Fossil 
users are on teams than not.

> subversion really shines here with its changelists

Some months ago, a proposal was made that I consider vastly superior to svn 
change lists: a flag for the stash command that would let you select and reject 
each hunk of the current diff interactively.

If you had three essentially unrelated changes in the current working copy, you 
could stash all the hunks belonging to two of them, then test the third change 
separately and check it in once you’re happy.  Then you could “stash pop” and 
repeat to polish the other two, one at a time.

It is important that this not be implemented in terms of checkin, since you 
need to test each unrelated feature separately before checking it in.

> == 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 f

Re: [fossil-users] features I'd like to have in fossil

[Andy Bradford]

Thus said Nikita Borodikhin on Fri, 21 Oct 2016 16:02:33 -:

> == 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.

You  could simply  open a  new checkout  and keep  unrelated changes  in
different checkouts of your repository. For example,

fossil new /tmp/test.fossil
mkdir /tmp/tinker && cd /tmp/tinker && fossil open /tmp/test.fossil
mkdir /tmp/explore && cd /tmp/explore && fossil open /tmp/test.fossil
mkdir /tmp/maybe && cd /tmp/maybe && fossil open /tmp/test.fossil

Etc...

> 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

By  ``label connected  files'' I  assume  you mean  related changes.  If
you're already doing the above  suggestion, there's always the option to
stash the changes.

Andy
-- 
TAI64 timestamp: 4000580a7267


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Svyatoslav Mishyn]

(Fri, 21 Oct 12:14) Warren Young:
> https://www.fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki

just found a typo:

Index: www/checkin_names.wiki
==
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -158,11 +158,11 @@
 
 In its default configuration, Fossil interprets and displays all dates
 in Universal Coordinated Time (UTC).  This tends to work the best for
 distributed projects where participants are scattered around the globe.
 But there is an option on the Admin/Timeline page of the web-interface to
-switch to local time.  The "Z" suffix on an timestamp check-in
+switch to local time.  The "Z" suffix on a timestamp check-in
 name is meaningless if Fossil is in the default mode of using UTC for
 everything, but if Fossil has been switched to local time mode, then the
 "Z" suffix means to interpret that particular timestamp using 
 UTC instead of local time.
 


-- 
I am not a native English speaker,
so feel free to correct any spelling or grammatical errors!


signature.asc
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Warren Young]

On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin  wrote:
> 
> == 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

For diff, simply install colordiff, which is almost certainly already packaged 
for your OS.  Then:

$ fossil set diff-command 'coloridff -wu'
$ fossil diff -r 2016-10-01 | less

> to group similar files together in a status report at a glance

Define “similar.”  Do you just mean that all the modified files should group 
together separate from the added files and such, or something different?

This is one of the areas where working code will speak louder than well-crafted 
prose.

> == change sets - preparing the change ==
> 
> I often end up having several sets of unrelated changes.

You admitted to not using branches, apparently because you don’t see the point 
of them in a single-developer project.  This is one good use for them.

That is, if you’re working on one feature and then see that you’ve gone off on 
a  tangent and are now building something unrelated, you can check the first 
feature’s unfinished changes into a branch, then return to the trunk to work on 
the second feature.

You’re using branches in this case to stash unfinished work without breaking 
the trunk or admixing unrelated features in a single checkin.

> Working with git, I use staging area to collect the needed changes and group 
> them together

I think the git staging area fights against team cohesiveness, primarily 
serving the needs of the sort of developer who likes to go off and hide in 
their office, not showing their work to their team members until it’s 
“perfect.”  Committing publicly, early, and often is objectively better, a fact 
that falls naturally out of the mathematics of control theory.

I realize that this is not a problem for you, but I’d guess that more Fossil 
users are on teams than not.

> subversion really shines here with its changelists

Some months ago, a proposal was made that I consider vastly superior to svn 
change lists: a flag for the stash command that would let you select and reject 
each hunk of the current diff interactively.

If you had three essentially unrelated changes in the current working copy, you 
could stash all the hunks belonging to two of them, then test the third change 
separately and check it in once you’re happy.  Then you could “stash pop” and 
repeat to polish the other two, one at a time.

It is important that this not be implemented in terms of checkin, since you 
need to test each unrelated feature separately before checking it in.

> == 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.

The solution to that is ag, The Silver Searcher:

  http://geoff.greer.fm/ag/

If you’re looking for a project, it would be nice if someone would teach ag 
about Fossil ignore rules.  It already knows about git, hg, and svn.  
Meanwhile, we have its built-in .agignore feature.

ag is awesome in many other ways.  In addition to being much faster than grep 
and with a shorter typical command line, it has much smarter defaults:

- color output
- case insensitive
- recursive on the current directory
- etc.

> == 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 initially missed that when moving from Fossil, but I retrained my muscle 
memory quickly enough.  I suppose it would be nice to have “fossil log” simply 
for those who can’t or won’t use Fossil enough to retrain, though.

> Ticket d1b50f4d06579e43c24d0e35f9d28d9562e95126 is the perfect example of 
> this.

Any unique prefix of a ticket ID will suffice.  (The same goes for all Fossil 
artifacts, in fact.)  You don’t have to paste all 40 characters of the hash.  
For ticket IDs, the first 4 or 5 characters should suffice.

It also would have been kind of you to give a URL rather than just the ticket 
ID.  Abbreviations are allowed here, too:

https://www.fossil-scm.org/index.html/tktview?name=d1b50

> == 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.

I think this is a result of Fossil