Re: [fossil-users] Bug report: Terrible Performance, when Checking in LLVM Source

[Nikita Borodikhin]

Try setting repo-cksum property off, it should help a lot.
By default Fossil double-checks all the files on disk to make sure their
contents is not changed.  That's fine for a small project, but for large
ones

Nikita

On Sat, Dec 3, 2016 at 8:29 PM Martin Vahi  wrote:

> Reproduction:
>
> 1) Download LLVM source.
>It might be done by executing the bash script from
>
>
> http://www.softf1.com/cgi-bin/tree1/technology/flaws/mmmv_parasail_projects.bash/artifact/3a28f1fb67a5d860
>
> 2) Commit the source.
>
> It is about 4.4GiB, over 100k files, over 6k folders,
> but it should not be that bad. After all, that's what
> many projects look like in 2016.
>
>
> Regards,
> martin.v...@softf1.com
>
> ___
> 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]

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] rebuild scale-ability/data written/repo size ratio

[Nikita Borodikhin]

Hi Karel,

as i understand this option, it is indeed for extra integrity checking.  It
checks all the files in your checkout, not only those involved in the
commit and allows to find data corruption on file system.

As other scms don't do that check (svn and git), I think it is safe to
leave it off.

Nikita.


On Sat, Oct 29, 2016, 13:34 Karel Gardas <gard...@gmail.com> wrote:

> Hi Nikita,
>
> your advice indeed helped a lot and brings commit to 20 seconds here.
> Now, the question is if I may really leave file integrity to
> file-system or if even ZFS/Btrfs is not enough here and fossil does
> some other magic?
>
> Thanks!
> Karel
>
> On Fri, Oct 28, 2016 at 7:33 PM, Nikita Borodikhin <elit...@gmail.com>
> wrote:
> > Hi Karel,
> >
> > I have quite a big repository (3.4G) imported from svn by a custom
> tool.  It
> > also took several minutes to commit, and most of the time was spent in
> md5
> > hash computation.  It is extra precaution to ensure checkout file
> integrity,
> > which can be turned off with repo-cksum setting.
> >
> > With that setting off, it takes 4 to 6 second to commit.
> ___
> 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] rebuild scale-ability/data written/repo size ratio

[Nikita Borodikhin]

Hi Karel,

I have quite a big repository (3.4G) imported from svn by a custom tool.
It also took several minutes to commit, and most of the time was spent in
md5 hash computation.  It is extra precaution to ensure checkout file
integrity, which can be turned off with repo-cksum setting.

With that setting off, it takes 4 to 6 second to commit.

My hardware is ext4 on Samsung 850 Pro 512 SSD, i7-3770

Nikita

On Fri, Oct 28, 2016, 10:03 Warren Young  wrote:

> On Oct 28, 2016, at 3:45 AM, Karel Gardas  wrote:
> >
> > make it more scale-able and allow its real usage also for projects of
> > bigger size.
>
> How many projects are there bigger than SQLite, percentage-wise?
>
> Has anyone done something like produce a SLOC histogram for all projects
> on GitHub or Sourceforge, so that we can say something like, “SQLite is in
> the top 2nd percentile for open source C projects based on SLOCCount’s line
> counting algorithm”?
>
> I’m intrigued enough to want to do the project, but I don’t think I really
> want to clone the entirety of GitHub onto my HDD in order to find out, even
> if it’s just one project at a time.  That sounds like a great way to blow
> through my Comcast data cap.
>
> > Let's talk about some real numbers to illustrate the situation.
>
> Yes, let’s. :)
>
> > $ time /opt/fossil-head/bin/fossil clone
> > http://netbsd.sonnenberger.org/ netbsd-src.fossil
> >
> > It takes:
> >
> > real323m2.323s
> > user42m0.262s
> > sys 13m18.003s
>
> Okay, but compared to what?
>
> If you compare to the checkout time from NetBSD’s main CVS repository, you
> aren’t comparing apples to oranges, since you’re transferring only the tip
> of the trunk.  You have to go back to the CVS server for any history.  I
> suspect if you checked out each CVS revision one at a time, it would take a
> lot longer than pulling the whole project history with Fossil.
>
> If you want to compare with some other DVCS, post those numbers.
>
> > rebuild alone
> > takes around 250 minutes on the same hardware and with the same
> > fossil.
>
> Would a --skip-rebuild option for fossil clone solve your major problem,
> then?
>
> Rebuilding is strictly optional.  It just makes Fossil operations run
> faster post-clone.
>
> Also realize that cloning is a one-time activity per development machine,
> for anyone active enough in the project to maintain their local clone.
>
> A cute option would be if --skip-rebuild would look for a local at(1)
> command, then offer to schedule the rebuild for a later time, after you’ve
> left off work for the day.
>
> Although there may be casual clients who clone, do something with the
> source, throw the clone repo away when done, then clone again a year later
> when they need the source again, we should not optimize Fossil for that
> case.
>
> We’ve already discussed shallow clones, which would make Fossil more like
> CVS in terms of clone size.  See the “Fossil 2.0” document Mr. Boogie
> linked to.
>
> > - commit, this is a little bit harder. One file modified and commit
> takes:
> > real4m0.765s
> > user1m55.442s
> > sys 1m11.892s
>
> That seems like a much more important problem to solve.  4 minutes per
> commit is simply *painful*, and it may happen multiple times per day,
> rather than once per development box.
>
> Here, I occasionally see commit times of 10 seconds or so, and that’s
> painful enough already.
> ___
> 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]

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

[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

[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

[Nikita Borodikhin]

Hi Warren,


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

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.

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 t

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 <elit...@gmail.com> 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

[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] Rebase solved

[Nikita Borodikhin]

Hi,

this is not a rebase, at least not in a sense of git.  Git rebase is,
basically, what you would get if you recreate someone's work from diffs
published to a mail list.  Rebase is an application of all commits, one by
one, from old branch to the new parent.  After rebase you get a _new_ set
of commits with the same commit messages etc in a new branch, which bears
no relation to the old one.  This is the main criticism of rebase - new
commits lose historic context of old commits.

Your proposal is what often called "merge from trunk" or "sync with trunk"
or "update to trunk" in svn world.  I personally like it more than git
rebase.  However, it is twisted in a very fossil way.  Regular merge would
be:
* f checkout branch-name
* f merge trunk
* f commit

Nikita

On Wed, Oct 12, 2016, 18:46 Andy Goth  wrote:

> The full history is there. Nothing is destroyed. The goal is to
> re-baseline the branch, which i accomplish by creating a new branch with
> the same name which is merged from the original. Thus there is both one
> check-in containing all past changes made on the branch, and also the
> branch from which it was derived containing the full history. So you have
> it both ways, although that fact is secondary to my goal.
>
> Bundles make sense for a totally different use case than I'm dealing with
> here. Every engineer has developer capabilities, and they directly check in
> their work onto branches.
>
> Because of other company processes with which I must interoperate, I must
> keep each "activity" on its own branch and reserve trunk for integration
> consisting of only merges. (Plus I keep several other integration branches
> for maintaining sync with ClearCase and Subversion which I am also required
> to support.) And so, I cannot implement updating a branch's effective
> baseline by merging in outside changes which are not related to the
> branch's activity. Hence my rebase method.
>
> Here's an untested example. I'm using my phone to write this, sorry.
>
> # Create repository
> f new food.fossil
> mkdir food
> cd food
> f open ../food.fossil
>
> # Create main dish
> echo eggs > breakfast
> f add breakfast
> f commit -branch breakfast -m Breakfast
> echo "scrambled eggs" > breakfast
> f commit -m "Specify how breakfast cooked"
>
> # Create side dish
> f up trunk
> echo spam > side
> f add side
> f commit -branch side -m "Side dish"
> echo "fried spam" > side
> f commit -m "Specify how eggs cooked"
>
> # Side is ready for consumption
> f up trunk
> f merge side
> f commit -m "Merge side"
>
> # Rebase breakfast to include side
> f up trunk # (Redundant in this case)
> f merge breakfast
> f commit -branch breakfast -m Rebase
>
> # Finish making breakfast
> echo "scrambled green eggs" > breakfast
> f commit -m "Specify color"
>
> # Review all breakfast changes
> f diff -from root:breakfast -to breakfast
> # Shows only breakfast, not side
>
> # Pull it all together
> f up trunk
> f merge breakfast
> f commit -m "Merge breakfast"
>
> On Oct 12, 2016 19:38, "Warren Young"  wrote:
>
> On Oct 12, 2016, at 6:12 PM, Andy Bradford 
> wrote:
> >
> > Thus said Andy Goth on Wed, 12 Oct 2016 16:25:43 -0500:
> >
> >> Comments?  Questions?  This  method  does everything  my  team  needs.
> >> Perhaps Fossil might  consider adopting it, or  a streamlined variant,
> >> so we'll  have an  answer to  the perennial question  about how  to do
> >> rebase.
> >
> > I honestly have not yet found the  need for ``rebase'' so I'm not really
> > sure what  I get out  of using it.  Maybe you can  put up a  demo Fossil
> > repository that shows just what your rebase looks like, and then what it
> > would look like without rebase?
>
> That, or just a command sequence whereby one could construct such a
> repository locally.
>
> I *think* I see what you’re trying to accomplish here, Mr. Goth, but I’m
> not quite sure it’s the same thing as Git rebase.  For one thing, doesn’t
> it leave a branch and all of its checkin history behind?  I thought its
> most famous use was to collapse a branch’s entire change sequence down to a
> single patch.
>
> Incidentally, as one who ran an active open source project, I always hated
> receiving big-ball-of-hackage patches that changed several essentially
> unrelated things.  I really don’t understand the charm in receiving a
> single flattened patch.  Fossil bundles are a much better idea.  I *want*
> to see the full checkin history.
> ___
> 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 mailing list
fossil-users@lists.fossil-scm.org