Just wanted to say we've been using Fossil for our development of
8th (http://8th-dev.com), and have been extremely happy with its
flexibility and robustness. Even when we *thought* it was messed
up, we were able to recover successfully.
After 30 years in the field,
Stephan Beal wrote:
> After a _filesystem_ error, fossil cannot trust anything. Throwing it away
> is as good as not, IMO. Had it NOT thrown it away, someone (quite possibly
> you!!!) would have complained that a useless, half-completed file was
> laying around.
When redoing an operation is fast,
On Sun, Jan 18, 2015 at 1:42 PM, Kelly Dean wrote:
> This is with Fossil 1.29.
>
> root@helpme:/mnt/hgfs/emacs# time git fast-export --all | fossil import
> --git emacs.fossil
> [A few hours later:]
> Rebuilding repository meta-data...
> [A day later:]
> 100.0% complete...
> Vacuuming...
> [A c
The branching.wiki page gives an example of a trunk branch with the ⌜trunk⌝
name, and a test branch from it that cancels the ⌜trunk⌝ name and adds the
⌜test⌝ name.
I can't think of any cases where it would make sense to have a branch X without
the name ⌜X⌝ or with the name ⌜Y⌝ where Y is anothe
On Sun, Jan 18, 2015 at 12:42 PM, Kelly Dean wrote:
> SQLITE_IOERR: os_unix.c:27527: (5) ftruncate(/mnt/hgfs/emacs/emacs.fossil)
> - Input/output error
> SQLITE_IOERR: statement aborts at 2: [VACUUM]
> fossil: disk I/O error: {VACUUM}
>
The I/O error was hgfs's fault, not Fossil's.
>
> However
This is with Fossil 1.29.
root@helpme:/mnt/hgfs/emacs# time git fast-export --all | fossil import --git
emacs.fossil
[A few hours later:]
Rebuilding repository meta-data...
[A day later:]
100.0% complete...
Vacuuming...
[A couple hours later:]
SQLITE_IOERR: os_unix.c:27527: (5) ftruncate(/mnt/h
6 matches
Mail list logo
