On 10/28/14, Jungle Boogie <jungleboog...@gmail.com> wrote: > Dear Richard, > -------------------------------------------- > From: Richard Hipp <d...@sqlite.org> > Sent: Tue, 28 Oct 2014 10:09:25 -0400 > To: Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> > Subject: Re: [fossil-users] Fossil checksum > > >> On Tue, Oct 28, 2014 at 10:00 AM, Stephan Beal <sgb...@googlemail.com> >> wrote: >> >>> i don't remember any numbers from that thread, but do remember one >>> quote. >>> When (whoever it was, probably Richard) explained that The Math shows >>> that >>> a collision is not likely to happen until some tens of thousands of >>> years >>> in the future, someone asked, "but what then?" >>> >>> >> (Back-of-the-envelop calculations follow:) >> >> If 6 billion people are all using the same Fossil repository and are >> doing >> one commit per second, 24 hours a day, 7 days a week, then there is a 50% >> chance of a collision after a little more than 6 million years. >> >> That same commit rate will cause Fossil to exceed its maximum repository >> size (140 terabytes) in about four minutes. >> >> > > Let's see that envelop! That's some great math! > > In all seriousness to all who replied, thanks for putting any possible > anxiousness to rest. > > Second question... > The reason some people/organizations prefer a non-distributed SCM (is that > the > proper term?)
"Centralized" is probably the word you're searching for. > is because you can delete commits and make it as if they never > > appeared. In the fossil like world, that's not possible if someone has > already > checked out a revision, but what can be done to prevent future checkouts? Is > > there a way to delete the commits and any traces of it? Fossil has a "shun" operation that is described here: http://fossil-scm.org/index.html/doc/tip/www/shunning.wiki Fossil is designed to show all work that is involved at each step, in perpetuity. In other words, it's like an accounting system where all transactions (and corrections to errors) are laid out as a record. Compare w/ git, for example, where "rebasing" will condense work, wiping out the record of exactly how that work was performed. Fossil wants to be honest about it's history, and git wants to beautify it's history. For this reason, "fiddling" with fossil is frowned upon, and support for (eg) rebasing is low (non-existent). That said -- I would like an option to "pop and discard" from a branch tip. Possible? If the repo has been sync'd, then that work would come back to you on next sync (that's understood), but if it hasn't been sync'd, it could be useful. -bch > Thanks, > jb > > -- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > xmpp: jungle-boo...@jit.si > _______________________________________________ > 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
