Re: [fossil-users] on sha1 as a hash

2016-10-18 Thread K. Fossil user 
Hi,
1/ Does Fossil use SHA1 ?OoToo bad if it is.At least I expect that we've got a 
choice : sha256, sha512, etc. ...

2/ However, when people use Fossil in a local PC, even MD5 should not be an 
issue.3/ Thanks for this reminder. 
 
Best Regards

K.

  De : bch 
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Mardi 18 octobre 2016 22h23
 Objet : [fossil-users] on sha1 as a hash
   
https://news.ycombinator.com/item?id=12737535
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Repository question

2016-10-18 Thread Richard Hipp 
On 10/18/16, Scott Doctor  wrote:
>
> Assume many check-ins occurred with many changes over many
> files. Seems that if something glitches everything can become
> out of sync and hard to recover. My question, is there is a way
> to tell fossil to store the complete versions of the documents
> instead of it recreating the documents by piecing all those
> fragments together. My concern is that something goes wrong,
> perhaps a bad disk sector not necessarily a software issue, that
> would further complicate recover.
>

Content is checked to make sure it is recoverable prior to running the
COMMIT that stores it in the database.  If any content is not
recoverable, Fossil runs a ROLLBACK instead. See
https://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for
further information.

To guard against hardware bugs damaging the database, clone the
database on multiple machines and keep them in sync automatically.
You are more likely to have a complete disk failure or some other
local disaster (a fire or flood) and loss everything than a single bad
sector.  Turning off the delta compression will not save you from a
flood or fire. So if you have important content, be sure to clone the
repo to multiple geographic locations.

The Fossil self-hosting repositories are stored on leased servers
located in three different data centers, each at least 500 miles
distant from the others.  Server space is leased from two different
companies to prevent a common-mode failure at a single ISP.  All
content is kept in sync using cron jobs that runs "fossil sync -u"
very hour or so.  And, of course, there are countless private clones
of Fossil that can also be used for recovery.

There was once a double-bug in Fossil and stunnel that corrupted the
canonical Fossil repository database, breaking the delta chain, and
making downstream content unrecoverable.  The first problem was that
stunnel was launching Fossil without opening file descriptor 2
(stderr).  The database was opened on the first available file
descriptor, which was 2.  Then a bug in Fossil caused an assert() to
fire which did write(2,...) to put an error message smack in the
middle of the database file.  All content was recovered using one a
clone.  SQLite was subsequently enhanced to never open a database
using a file descriptor less than 3 so this error can never happen
again.  But who knows what other subtle problems lurk undetected.
Also clone data you care about.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Repository question

2016-10-18 Thread Scott Doctor 


The fossil wiki states that Check-ins are normally stored in the 
repository in a highly space-efficient compressed format (delta 
encoding).


Assume many check-ins occurred with many changes over many 
files. Seems that if something glitches everything can become 
out of sync and hard to recover. My question, is there is a way 
to tell fossil to store the complete versions of the documents 
instead of it recreating the documents by piecing all those 
fragments together. My concern is that something goes wrong, 
perhaps a bad disk sector not necessarily a software issue, that 
would further complicate recover.



--

-
Scott Doctor
sc...@scottdoctor.com
-

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] on sha1 as a hash

2016-10-18 Thread bch 
https://news.ycombinator.com/item?id=12737535
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users