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

31–40 of 91 posts

Re: Fossil SCM keeps more than just your code

#31

Post by Fice »

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 analogous workflow in fossil?

Private branches: https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

Re: Fossil SCM keeps more than just your code

#32

Post by sgbeal »

pdw wrote: post #28
sgbeal wrote: post #20

Earlier quoted context omitted.

> 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.

i've been on the fossil dev team since 2008, and i have seen many people claim that it "could" be compromised/modified post facto, and yet... nobody has been able to do it. Fossil's core data model does not just _assume_ that history doesn't change - it makes it essentially impossible to do.

Shunning is a special case which removes a given artifact from the db, but is considered a "nuclear option" of last resort. i've never personally used it.

Re: Fossil SCM keeps more than just your code

#33

Post by sgbeal »

avar wrote: post #26
sgbeal wrote: post #22

Earlier quoted context omitted.

> 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 ne…

Why do you feel that you _have_ to be able to correct history? The past is immutable. Fossil treats it as such. git does not, no matter what configuration you're running - i can always create a fork, modify the history in my fork, and publish that. git has mutable history, period. fossil does not, period. They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes.

Re: Fossil SCM keeps more than just your code

#34

Post by JustSomeNobody »

speps wrote: post #25

By the way, does anyone know of a SCM written in Go? It seems that the feature list of Fossil would fit Go pretty well, the networking/local web UI stuff for example, self-contained binary as well.

They should all be written in ANSI C. C90, specifically.

Re: Fossil SCM keeps more than just your code

#35

Post by adwn »

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.

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

I work for a company that builds machines to be sent into space (specifically, electronics and high-tech instruments), and I have never heard of such a requirement. The end result matters to our customers, not the thousands of commits in our Subversion repository.

Re: Fossil SCM keeps more than just your code

#36

Post by CodexArcanum »

I was introduced to Fossil through a previous HN post and I love it. For smaller personal projects, it's the best. I like that I can just put the repo file into Dropbox and then have my project's tickets, documentation, and code all in one place.

And from someone who doesn't write much C, I will say that the source is very easy to read and poke around in. Just a great project all around.

Re: Fossil SCM keeps more than just your code

#37

Post by falcolas »

madeofpalk wrote: post #24
w_t_payne wrote: post #15

Earlier quoted context omitted.

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.

Similar here. If the todo survives the development branch, it should be moved into the ticketing system. Otherwise, you have two ticketing systems, one of which will be forgotten when it comes time to prioritize new development.

Re: Fossil SCM keeps more than just your code

#38

Post by sspiff »

I use Fossil for personal, private projects. I've never used it with other people. But being able to replicate the wiki, issues etc and version them is very cool.

I use fossil to keep track of my code and use the wiki of a project as a scratchpad, design document, and general notes. I love it.

It can be self-hosted using a super-simple CGI script:

    #!/usr/bin/fossil
    repository: /path/to/project/repository.fossil
- which allows you to both clone over HTTP/HTTPS and access the Wiki and issue tracker via your browser. It has pretty decent access control and can allow you to configure a set of wiki pages to make read-only accessible to everyone, even when not logged in, to use as a project landing page for visitors.

You can also customize the CSS of a project, which is also versioned in the single sqlite db backing a repository.

Re: Fossil SCM keeps more than just your code

#39

Post by falcolas »

JustSomeNobody wrote: post #34
speps wrote: post #25

By the way, does anyone know of a SCM written in Go? It seems that the feature list of Fossil would fit Go pretty well, the networking/local web UI stuff for example, self-contained binary as well.

They should all be written in ANSI C. C90, specifically.

I appreciate the motivation behind this ideology, but giving up 26 years of advancement in programming languages (not to mention security and safety) for compatibility with a vanishingly small number of operating systems (few, if any, of which are in use as development machines) is not worth it for tools like these.

Re: Fossil SCM keeps more than just your code

#40

Post by masklinn »

panic wrote: post #11
thecatspaw wrote: post #2

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? Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightw…

What happens if you accidentially add code where you dont own the copyright? Or an API Secret? http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki

So… not that different from git after all? (rebasing creates new revisions, but while the old ones may not be trivially accessible anymore they're still there until garbage collected)
Post reply on HN