Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil SCM keeps more than just your code

blog.kotur.org

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Fossil SCM keeps more than just your code

#21

Post by sgbeal »

wereHamster wrote: post #6

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the interna…

> Ehm, That's not a fair assessment. Git is as much immutable as fossil.

HA! HAHA! HAHAHA!!!!

For any reasonable definition of "immutable," git is most certainly NOT immutable.

Re: Fossil SCM keeps more than just your code

#22

Post by sgbeal »

jimktrains2 wrote: post #13
wereHamster wrote: post #6

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the interna…

> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm work…

> What is the value in having history be static?

auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.

Re: Fossil SCM keeps more than just your code

#23

Post by jordigh »

koko775 wrote: post #16
jordigh wrote: post #3

This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal. Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy. With offerings like gitlab, it might not make…

> Almost nobody uses just git -- they use github or gitlab. Your points are made in a needlessly provocative manner. Tons of people roll their own interfaces to their source control, and a lot of people benefit from somewhat centralized repositories. Not only is there room for both, but I don't see any data indicating how prevalent private, non-GitHub repositories are, or how those would even be counted accurately gi…

> Tons of people roll their own interfaces to their source control,

And how do they compare with github's megatons? I argue the numbers are not comparable. My most generous estimate is that less than 5% of all git users work without ever touching Github.

> Mercurial isn't as popular as git, but neither are dependent on GitHub/bitbucket for continued relevance.

I am convinced that if anything ever replaces git, it will have to come with a website that greatly simplifies deploying software. Git alone is not enough for sharing with the masses -- it requires Github or equivalent. I am also certain that git's meteoric rise would have been completely impossible without Github.

Every time I see a newcomer trying to deploy a Mercurial repo, I see them struggling with Bitbucket's implementation of hg hosting. It pains me that there is nothing better to direct them to.

Re: Fossil SCM keeps more than just your code

#24

Post by madeofpalk »

w_t_payne wrote: post #15
w_t_payne wrote: post #14

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or som…

It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.

> sort of like a TODO but with super-powers.

Funnily enough our team just introduced an eslint warning (https://github.com/eslint/eslint/blob/master/docs/rules/no-w...) to discourage those TODO comments as we found they just always sat around forever collecting lint.

Re: Fossil SCM keeps more than just your code

#26

Post by avar »

sgbeal wrote: post #22
jimktrains2 wrote: post #13

Earlier quoted context omitted.

> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm work…

> What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.

That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you.

What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew.

Nobody needs audibility on unfinished work that hasn't been pushed to the central repositories (and would thus be protected by non-fast-forward).

To the extent that you would fossil doesn't make the situation better, if I can't fix up my commits after the fact before I push them I'm just not going to make those intermediate commits in the first place, which gives the system no more information to work with, and results in a less convenient workflow for me.

This whole "we preserve history forever" statement is a red herring. They've just picked a data model which is hard-immutable, but it doesn't mean that they're categorically preserving more information, or that tools that have configurable-immutable datamodels (like Git) preserve less history in practice.

Re: Fossil SCM keeps more than just your code

#27

Post by jordigh »

crististm wrote: post #17
jordigh wrote: post #10

Earlier quoted context omitted.

I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?

We don't know how many people are using SSH git but you surely know they are much less than 3 million. Have you heard about Dunning-Kruger effect?

Yes, I assume you are indicating that I think my skill is greater than it actually is? Which skill are you referring to? Or whose skill are you referring to?

Re: Fossil SCM keeps more than just your code

#28

Post by pdw »

sgbeal wrote: post #20
ibmthrowaway271 wrote: post #5

Earlier quoted context omitted.

> In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.

> Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history. No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.

Git is the same, if you rebase many hashes will be recalculated, and the "tampering" would be obvious to anyone who had a copy of the repository. It is possible to implement the equivalent of rebase in any distributed VCS, the authors of Fossil simply chose not to. If it becomes more popular, somebody else likely will.

Re: Fossil SCM keeps more than just your code

#29

Post by thechriswalker »

sgbeal wrote: post #20
ibmthrowaway271 wrote: post #5

Earlier quoted context omitted.

> In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.

> Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history. No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.

From what I just read, the "shun" method means that you can rewrite history by adding a shun, rebuilding a copy, then switching copies.

Not db rewrite, but the same end result.

edit: bad english

Re: Fossil SCM keeps more than just your code

#30

Post by dcuthbertson »

jimktrains2 wrote: post #13
wereHamster wrote: post #6

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the interna…

> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm work…

> What is the value in having history be static?

[Edited for formatting]

Section "3.9 Audit Trail" of "http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki" puts it best. It's about being able to audit the history, instead of using history as a kind of documentation of the intent of the changes:

    Git features the "rebase" command which can be used to
    change the sequence of check-ins in the repository. 
    Rebase can be used to "clean up" a complex sequence of
    check-ins to make their intent easier for others to
    understand. This is important if you view the history of 
    a project as part of the documentation for the project.

    Fossil takes an opposing view. Fossil views history as
    sacrosanct and stubbornly refuses to change it. Fossil
    allows mistakes to be corrected (for example, check-in
    comments can be revised, and check-ins can be moved onto 
    new branches even after the check-in has occurred) but
    the correction is an addition to the repository and the
    original actions are preserved and displayed alongside
    the corrections, thus preserving an historically
    accurate audit trail. This is analogous to an accounting 
    practice of marking through an incorrect entry in a
    ledger and writing a correction beside it.

    To put it another way, Git remembers what you should
    have done whereas Fossil remembers what you actually
    did.

    The lack of a "rebase" command and the inability to
    rewrite history is considered a feature of Fossil, not
    an omission or bug.
Post reply on HN