Re: [fossil-users] fossil 1.34 segfault on git import

On Sun, Dec 27, 2015 at 10:23 PM, Richard Hipp wrote: > However, one side effect of the Git clone effort is that the > fast-import logic of Fossil has been improved. It should run faster > now, and use a lot less disk space. Can you please try your import > again and let us

Re: [fossil-users] fossil 1.34 segfault on git import

g> wrote: > On 12/29/15, Karel Gardas <gard...@gmail.com> wrote: >> On Sun, Dec 27, 2015 at 10:23 PM, Richard Hipp <d...@sqlite.org> wrote: >>> However, one side effect of the Git clone effort is that the >>> fast-import logic of Fossil has been improved. It s

Re: [fossil-users] fossil 1.34 segfault on git import

1.2 GB. Let me know if this is all right for you to download from some free service and I'll start upload which will also take some time... On Thu, Dec 31, 2015 at 2:02 PM, Richard Hipp <d...@sqlite.org> wrote: > On 12/31/15, Karel Gardas <gard...@gmail.com> wrote: >> >

Re: [fossil-users] fossil 1.34 segfault on git import

On Mon, Dec 21, 2015 at 6:20 PM, Richard Hipp <d...@sqlite.org> wrote: > On 12/21/15, Richard Hipp <d...@sqlite.org> wrote: >> On 12/20/15, Karel Gardas <gard...@gmail.com> wrote: >>> >>> Is there anything I shall try or provide you with to duplicate

[fossil-users] fossil 1.34 segfault on git import

Hello, my attempt to import bitrig OS git src tree into fossil failed with segfault. This is done on OpenBSD 5.8 current , fossil is compiled from the ports tree, git is provided also from ports tree. $ git --version git version 2.6.2 $ fossil version This is fossil version 1.34 [62dcb00e68]

Re: [fossil-users] fossil 1.34 segfault on git import

On Sun, Dec 27, 2015 at 10:23 PM, Richard Hipp wrote: > Still working on the ability to clone a Git repository - that feature > is not ready yet. I've seen your documentation changes with regarding to hierarchical manifests. Great think you specify first. > However, one side

Re: [fossil-users] fossil 1.34 segfault on git import

> I've seen your HEAD changes, I'm on 2dd25909da and the > space-effeciency is really nice to have. I'm not sure if this is > faster than in the past since I'm not testing on the same hardware > setup. I'll see if it crashes or not and if not, then I'll fire on the > original test server and test

Re: [fossil-users] fossil 1.34 segfault on git import

On Mon, Dec 28, 2015 at 8:42 PM, Karel Gardas <gard...@gmail.com> wrote: >> I've seen your HEAD changes, I'm on 2dd25909da and the >> space-effeciency is really nice to have. I'm not sure if this is >> faster than in the past since I'm not testing on the same har

Re: [fossil-users] fossil 1.34 segfault on git import

>>> I've seen your HEAD changes, I'm on 2dd25909da and the > I'm not sure if this is related, but I've not followed the process for > whole time, but seen that during the meta-data rebuild it quite grows > in memory. While being at 37% of rebuild it was already eating around > 330 MB of RAM. So my

Re: [fossil-users] Any way how to optimize/speed-up meta-data rebuild?

Will test --no-rebuild once current rebuild is done. Thanks for the note! On Tue, Feb 9, 2016 at 4:39 PM, Richard Hipp <d...@sqlite.org> wrote: > On 2/9/16, Richard Hipp <d...@sqlite.org> wrote: >> On 2/9/16, Karel Gardas <gard...@gmail.com> wrote: >>> Hello

[fossil-users] Incremental import breaks repo.

Hello, after attempting incremental import from OpenBSD src git tree, I've found out that when I try to fossil open such repository I get only files changed by the last import and not the files held by the whole repository. Anyway, the repository still holds the files I'm sure: $ sqlite3

Re: [fossil-users] Incremental import breaks repo.

On Tue, Feb 9, 2016 at 10:28 PM, Richard Hipp <d...@sqlite.org> wrote: > On 2/9/16, Karel Gardas <gard...@gmail.com> wrote: >> is this a known issue or do I do something completely wrong? >> > > Neither. You are dealing with seldom-used functionality that

Re: [fossil-users] Compiling and running Fossil on old hardware

On Sat, Feb 13, 2016 at 8:25 PM, Stephan Beal wrote: >> I use an old IBM Thinkpad 240. It has 256MB of RAM and a 300Mhz Celeron >> and a 6GB hard drive. It's running OpenBSD 5.8 and it took a long time >> to clone the Fossil repository on it. Most of the time was

Re: [fossil-users] Bitrot defense?

You need to use something like RAID1 setup with N drives using either ZFS or btrfs. If you are on dragonfly bsd probably hammer does that too. Also backup and scrub your disk array quite often... Ah, just found out that zfs/btrfs is also cited by the article so you already know that... On Tue,

Re: [fossil-users] Incremental import breaks repo.

o form one line of development which is really what's in to fossil imported git repo? Thanks! Karel On Tue, Feb 9, 2016 at 10:32 PM, Karel Gardas <gard...@gmail.com> wrote: > On Tue, Feb 9, 2016 at 10:28 PM, Richard Hipp <d...@sqlite.org> wrote: >> On 2/9/16, Karel Garda

Re: [fossil-users] Incremental import breaks repo.

On Fri, Sep 2, 2016 at 8:28 PM, Svyatoslav Mishyn wrote: > Maybe `fossil reparent` and then `fossil leaves --recompute` will help.. > Great! This is indeed working as long as there is acceptable to have additional artifacts -- are those tags? My testing timeline shows this:

Re: [fossil-users] Incremental import breaks repo.

./test.sh -- also please modify reconnect.sh first and if your GNU grep is "grep" then please rename "ggrep" to "grep". The scripts were developed on my Solaris workstation where GNU grep is ggrep. Thanks! Karel On Sat, Sep 3, 2016 at 8:26 PM, Karel Gardas <gard..

[fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)

Hello, while building fossil-head just from minutes ago, my compiler on Solaris 11.2 complain about: cc -I. -I../src/src -Ibld -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DFOSSIL_DYNAMIC_BUILD=1 -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -o bld/doc.o -c bld/doc_.c "../src/src/doc.c", line

Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)

On Mon, Aug 29, 2016 at 5:38 PM, Richard Hipp <d...@sqlite.org> wrote: > On 8/29/16, Karel Gardas <gard...@gmail.com> wrote: >> Hmm, conversation suggest that this is not bug in the code but trivial >> user error. OK! > > Half-true. Your original bug repo

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

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

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

On Fri, Oct 28, 2016 at 7:02 PM, Warren Young <w...@etr-usa.com> wrote: > On Oct 28, 2016, at 3:45 AM, Karel Gardas <gard...@gmail.com> wrote: >> >> make it more scale-able and allow its real usage also for projects of >> bigger size. > > How many projects a

Re: [fossil-users] OT: Facebook engineers preferring hg to Git

On Thu, Oct 27, 2016 at 1:37 PM, David Mason wrote: > I's about 1/3 of the way through this report: > https://groups.google.com/forum/#!topic/mozilla.dev.version-control/nh4fITFlEMk > > It seems that they originally preferred GIT (because it was what they knew) > but now prefer

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

Hello, first of all, I know that Fossil was written with the idea of serving SQLite project and projects of similar size well and that it does great job in this task. I'm just curious if there are people here tinkering with the idea to make it more scale-able and allow its real usage also for

Re: [fossil-users] OT: Facebook engineers preferring hg to Git

On Fri, Oct 28, 2016 at 1:33 PM, Richard Hipp wrote: > On 10/27/16, David Mason wrote: >> >> However, the value of Rust is not simply memory management. The >> *considerably* more expressive type system, and the much more robust type >> checking can reduce

[fossil-users] git incremental import speedup.

Hello, first of all thanks a lot to the developer(s) who fixed import and incremental import from git to fossil. I'm now able to import OpenBSD source tree from OpenBSD src git mirror to fossil. Anyway, there is small nitpick. While using incremental import on such repo, fossil is horribly slow.

Re: [fossil-users] git incremental import speedup.

On Wed, Oct 26, 2016 at 11:53 PM, Adam Jensen <han...@riseup.net> wrote: > On 10/26/2016 05:37 PM, Karel Gardas wrote: >> I'm now able to import OpenBSD >> source tree from OpenBSD src git mirror to fossil. > > This might be a silly question since I am terribly uniforme

Re: [fossil-users] git incremental import speedup.

On Wed, Oct 26, 2016 at 11:44 PM, jungle Boogie <jungleboog...@gmail.com> wrote: > On 26 October 2016 at 14:37, Karel Gardas <gard...@gmail.com> wrote: >> Anyway, there is small nitpick. While using incremental import on such >> repo, fossil is horribly slow.

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

On Sun, Dec 4, 2016 at 9:55 PM, Joerg Sonnenberger wrote: > No. What repo checksum does is compute a separate checksum over the > concatenation of all files. Uf, so I've been completely off the picture. Thanks for correction! ___

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

On Sun, Dec 4, 2016 at 8:57 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > On Sun, Dec 04, 2016 at 08:50:44PM +0100, Karel Gardas wrote: >> Otherwise as Nikita recommended, switching off repo checksums helps a >> lot, but then make sure you are on the filesystem like ZF

Re: [fossil-users] Perception of Fossil

On Mon, 18 Jun 2018 00:01:33 +0300 John Found wrote: > > Please no, this would be real security nightmare. Anyone can attack any > > fossil public repo then by simple DoS. Do not ever allow anonymous to play > > with your pristine repository! If anon needs to "push" something, then > > he/she

Re: [fossil-users] Perception of Fossil

On Fri, 15 Jun 2018 13:35:13 -0400 Richard Hipp wrote: > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get

[fossil-users] How serious are test failures on 2.4 release.

Hello, I've been always wondering how serious are various failures man gets from building/testing fossil release. For example taking 2.4 release I get those: [...] This page was generated in about 0.009s by Fossil 2.4 [a0001dcf57] 2017-11-03 09:29:29 * Final results: 19 errors out