Re: [fossil-users] rebuild scale-ability/data written/repo size ratio

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

Re: [fossil-users] rebuild scale-ability/data written/repo size ratio

nough 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 &g

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

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

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

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

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

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, > &

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

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 bo

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

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

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

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 chan

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

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

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

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

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

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

Re: [fossil-users] Rebase solved

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

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

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: