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:
>
>
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...@g
il does
> some other magic?
>
> Thanks!
> Karel
>
> On Fri, Oct 28, 2016 at 7:33 PM, Nikita Borodikhin
> 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,
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
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
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 signifi
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:
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
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
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
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 examp
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 mak
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
13 matches
Mail list logo