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

[Nikita Borodikhin]

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 

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

[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

[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 

Re: [fossil-users] Can fossil bind to a single address?

[K. Fossil user]

Hi,
However, xinetd or inetd are not recommended...

Best Regards

K.

  De : Nathaniel Reindl 
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Vendredi 21 octobre 2016 21h48
 Objet : Re: [fossil-users] Can fossil bind to a single address?
   
On Fri, Oct 21, 2016, at 05:28 PM, Steven Gawroriski wrote:
> Is Fossil able to bind to a single IP address? There is `--localhost`

It doesn't seem that way, no. I've personally worked around it by employing 
tcpsvd from Gerrit Pape's excellent ipsvd package. The inetd super server (and 
its descendants) provide similar functionality.

In my runit run script, modulo tcpsvd-specific details not relevant here, I 
have `exec tcpsvd 127.0.1.6 3000 fossil http /data/fossil/root --https`, and 
that seems to work well when using a reverse proxy to send traffic to it via 
something like Apache, HAProxy, or an Amazon ELB. —n
___
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

[fossil-users] Fossil with multiple page bodies and cannot handle queries?

[Steven Gawroriski]

Hello,

Using fossil with xinetd using the following settings, browsing
repositories via the web interface does not work properly. My xinetd is
the one from Debian jessie.

service fossilmpa
{   
type = UNLISTED
bind = 208.77.100.8
port = 8080
socket_type = stream
protocol = tcp
flags = NODELAY
group = repompa
user = repompa
wait = no
cps = 1000
server = /usr/local/bin/fossil
server_args = http /repos/mpa/squirreljme.fossil --nossl --host
multiphasicapps.net:8080
}

Using a web browser such as Dillo or w3m, you essentially get content
showing up multiple times and queries being dropped.

 * 
 * 
 * 

If you browse it using Firefox, you see a snipped off HTTP query.

If I change xinetd to just forward the connection to a local address it
works fine however.

If I run the following command locally: `echo -en
"GET /doc/ckout/readme.mkd\r\n\r\n" | fossil
http /repos/mpa/squirreljme.fossil --nossl --host
multiphasicapps.net:8080` then it will send me multiple bodies on the
output.


___
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] Can fossil bind to a single address?

[Nathaniel Reindl]

On Fri, Oct 21, 2016, at 05:28 PM, Steven Gawroriski wrote:
> Is Fossil able to bind to a single IP address? There is `--localhost`

It doesn't seem that way, no. I've personally worked around it by employing 
tcpsvd from Gerrit Pape's excellent ipsvd package. The inetd super server (and 
its descendants) provide similar functionality.

In my runit run script, modulo tcpsvd-specific details not relevant here, I 
have `exec tcpsvd 127.0.1.6 3000 fossil http /data/fossil/root --https`, and 
that seems to work well when using a reverse proxy to send traffic to it via 
something like Apache, HAProxy, or an Amazon ELB. —n
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Can fossil bind to a single address?

[Steven Gawroriski]

Hello,

Is Fossil able to bind to a single IP address? There is `--localhost`
but that binds to 127.0.0.1 and `--port` for the port. However I would
like to listen on specific addresses, such as say 127.0.4.2 or a
specific public address. Right now to do this I have to host a server
with `--localhost` and have another web server act as a proxy to the
Fossil server (it just forwards requests to the local server). I would
rather have a setup where Fossil can listen on a specific address
directly. Supporting this would mean that I would only need the Fossil
binary.
___
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 
 À : Fossil SCM user's discussion  
 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  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, 

Re: [fossil-users] Can fossil bind to a single address?

[Nathaniel Reindl]

On Oct 21, 2016, at 18:55, K. Fossil user  
wrote:
> However, xinetd or inetd are not recommended...

That ellipsis really should be filled in with more details. Would you perhaps 
be willing to elaborate a bit on what you mean? —n
___
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] Can fossil bind to a single address?

[jungle Boogie]

Wait, what's wrong with inetd?
___
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

[fossil-users] How git does "fossil up 2016-08-01"

[Warren Young]

I just had to share this blog post, which I found last night:

http://blog.endpoint.com/2014/05/git-checkout-at-specific-date.html

Yes, the Git alternative to “fossil up 2016-08-01” is

$ git checkout `git rev-list -n 1 --before=2016-08-01 master`

…and it takes a long blog post to explain why.

Oh, and it takes much longer, because as I understand it, Git must traverse the 
entire checkin history to find out which checkin “2016-08-01” refers to.


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

[fossil-users] Broke repository using command line.

[Venkat Iyer]

Greetings,

Due to some ill-conceived advice and over-enthusiastic scripting,  I
managed to execute a command like this:

fossil ticket set e9d34a2552 +icomment "ivenkat added on
2016-10-21.18:50:20 PDT:
script checked in to [1a8ae0e34f]"

This failed with

SQLITE_ERROR: table ticketchng has no column named +icomment
fossil: table ticketchng has no column named +icomment
INSERT INTO
ticketchng(tkt_id,tkt_mtime,"+icomment",tkt_rid)VALUES(272,:mtime,..

No problem. I fixed my command.   But this broke all syncs.   A rebuild
of the db comes back with the same error:

ivenkat@a4x128-05 sdc]$ fossil rebuild
  98.0% complete...
SQLITE_ERROR: table ticketchng has no column named +icomment
fossil: table ticketchng has no column named +icomment
INSERT INTO ticketchng(tkt_id,tkt_mtime,"+icomment",tkt_rid)VALUES(...

Another DB that was sync'ing with this also fails to sync:

fossil sync
Sync with http://  
Round-trips: 1   Artifacts sent: 0  received: 2
SQLITE_ERROR: table ticketchng has no column named +icomment
fossil: table ticketchng has no column named +icomment
INSERT INTO
ticketchng(tkt_id,tkt_mtime,"+icomment",tkt_rid)VALUES(239,:mtime,'{

This is fossil version 1.35 [d8db91] 2016-01-17 22:12:21 UTC

My checkins on other sites have now halted  :O.

I tried to find where that +icomment was coming from without much success.
Any advice appreciated.   Fossil sqlite3 hackery is fine.

Thanks

 -Venkat
___
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] Broke repository using command line.

[Warren Young]

On Oct 21, 2016, at 10:22 PM, Venkat Iyer  wrote:
> 
> Due to some ill-conceived advice and over-enthusiastic scripting

Do you have some TH1 scripts (hooks, etc) installed?  If so, can you share them?

> fossil ticket set e9d34a2552 +icomment "ivenkat added on 2016-10-21.18:50:20 
> PDT:
> script checked in to [1a8ae0e34f]"
> 
> This failed with 
> 
> SQLITE_ERROR: table ticketchng has no column named +icomment

Isn’t that supposed to append your string to the icomment field, not look for a 
+icomment column?

What do you get from


$ fossil sql '.schema ticketchng'

> I fixed my command.   But this broke all syncs.

If your other DBs were up to date except for this recent change, you could just 
copy one of those clones over and use that as the new master.  You’ll have to 
set up some things that fossil clone doesn’t copy over (e.g. user passwords) 
but it might be less trouble than fixing the broken repo.
___
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] Broke repository using command line.

[Venkat Iyer]

Hi Warren,

Thanks for the reply.   No TH1 scripts, no hooks.   The only customization
is adding "assigned_to" in the ticket through the GUI.

The icomment stuff must have recently changed.   "User Comments" is
different than "comments".   I used to do +comments and that used to append
to the end of the ticket before.But if I do that now, it shows up
*before* the user comments entered from the web, which is confusing.

So based on someone's advice on the tcl chat I did icomments.   But I
mistakenly added a + though apparently I shouldn't have.

[ivenkat@a4x128-05 regs]$ fossil sql '.schema ticketchng'
CREATE TABLE ticketchng(
  -- Do not change any column that begins with tkt_
  tkt_id INTEGER REFERENCES ticket,
  tkt_rid INTEGER REFERENCES blob,
  tkt_mtime DATE,
  -- Add as many fields as required below this line
  login TEXT,
  username TEXT,
  mimetype TEXT,
  icomment TEXT
);
CREATE INDEX ticketchng_idx1 ON ticketchng(tkt_id, tkt_mtime);

Thanks

-Venkat



On Fri, Oct 21, 2016 at 9:30 PM, Warren Young  wrote:

> On Oct 21, 2016, at 10:22 PM, Venkat Iyer  wrote:
> >
> > Due to some ill-conceived advice and over-enthusiastic scripting
>
> Do you have some TH1 scripts (hooks, etc) installed?  If so, can you share
> them?
>
> > fossil ticket set e9d34a2552 +icomment "ivenkat added on 2016-10-21.18:50:20
> PDT:
> > script checked in to [1a8ae0e34f]"
> >
> > This failed with
> >
> > SQLITE_ERROR: table ticketchng has no column named +icomment
>
> Isn’t that supposed to append your string to the icomment field, not look
> for a +icomment column?
>
> What do you get from
>
>
> $ fossil sql '.schema ticketchng'
>
> > I fixed my command.   But this broke all syncs.
>
> If your other DBs were up to date except for this recent change, you could
> just copy one of those clones over and use that as the new master.  You’ll
> have to set up some things that fossil clone doesn’t copy over (e.g. user
> passwords) but it might be less trouble than fixing the broken repo.
> ___
> 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] Broke repository using command line.

[Warren Young]

On Oct 21, 2016, at 10:39 PM, Venkat Iyer  wrote:
> 
> Thanks for the reply.   No TH1 scripts, no hooks.   The only customization is 
> adding "assigned_to" in the ticket through the GUI.   

Actually, I can replicate this with a clean repo:

mkdir x
cd x
f new ../x.f
f open ../x.f 
f ticket add icomment foo
f ticket set $(f ticket show 0 | tail -1 | awk '{print $2}’) +icomment bar

That’s with the tip of trunk, updated just now.  ([7c7597220a])

> So based on someone's advice on the tcl chat I did icomments.   But I 
> mistakenly added a + though apparently I shouldn't have.

According to fossil help ticket, that sounds perfectly sane to me.  So, either 
the docs are wrong, there is a bug, or both I and your tcl chat correspondent 
are confused by the same thing.
___
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 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