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
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
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:
>>
>
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
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]
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
> 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
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
>>> 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
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
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
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
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
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,
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
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:
./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..
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
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
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
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
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
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
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
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.
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
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.
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!
___
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
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
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
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
32 matches
Mail list logo