Fossil SCM keeps more than just your code • Hacker News Board

Re: Fossil SCM keeps more than just your code

#51

Post by SQLite » Tue, Dec 15, 2015, 2:24 PM UTC

thechriswalker wrote: post #29

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.

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

That won't work because the SHA1 hashes won't match up.

If you accidentally check-in proprietary or sensitive content that you didn't mean to publish, you can shun that content. Shunning leaves a hole in your history. There is no way to replace that hole with different content.

Re: Fossil SCM keeps more than just your code

#52

Post by sgbeal » Tue, Dec 15, 2015, 2:27 PM UTC

jimktrains2 wrote: post #42

sgbeal wrote: post #33

Earlier quoted context omitted.

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

> Why do you feel that you _have_ to be able to correct history? Why do you feel I shouldn't be able to do what I want with my history before others see it? Shared repos can reject history rewrites, as the parent said. Also, as others have said, fossil does not provide the tools to mutate history, but that doesn't mean that history is immutable. > They are different mindsets. i personally don't mind my mistakes stayi…

"Mistakes" was indeed a poor choice of words, but the principle is the same: fossil does not allow the public record (mistake or otherwise) to change, with the one exception of the "nuclear option" (shunning, which forcibly removes content from the repo).

git allows the public record to be flexible forever. "History is written by the victors." Fossil believes that everything in the repo is in the public record and that the public record must never change. "History is recorded as it happened."

Re: Fossil SCM keeps more than just your code

#53

Post by krupan » Tue, Dec 15, 2015, 2:31 PM UTC

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…

Rewriting history was considered Very Bad by most everyone who had not yet used distributed version control much. The set of people that had not yet used distributed version control much included everyone, even the developers of distributed version control tools. After we all started using DVCSes more we realized how useful and powerful it was to be able to rewrite local history.

Fossil developers are apparently still catching up to this idea but as pointed out in other replies here it does have some history rewriting features. Even its recommendation that you pull and merge others' changes with yours before you commit your changes (in the style of CVS or SVN, they call it "autosync") is a form of rewriting history. See: http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki

Re: Fossil SCM keeps more than just your code

#54

Post by data_hope » Tue, Dec 15, 2015, 2:36 PM UTC

sgbeal wrote: post #33

avar wrote: post #26

Earlier quoted context omitted.

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

uh, this is a very pessimistic view on history rewriting.

Much more common probably is the fact that one tries to persist very gradually local changes, and once the dust has settled, submit a much coarser commit. Because most of the time all these "fixup this", "add missing imports" commits are really of nobodies interest any more.

If you hold on to a git hash, you are can identify history changes very easily.

Re: Fossil SCM keeps more than just your code

#55

Post by feld » Tue, Dec 15, 2015, 2:40 PM UTC

jimktrains2 wrote: post #9

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…

> Having Tickets, the Wiki and technotes in the same place is an interesting idea, Couldn't you just have a `bugs`, and `notes` branch? gugs would be a folder per bug, with each message being a MIME or some similar message format. notes would be a collection of md, rst, textile, &c similar to how github already has a gh-pages branch. It wouldn't need to be part of the scm, but simply be convention.

This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.

Re: Fossil SCM keeps more than just your code

#56

Post by wereHamster » Tue, Dec 15, 2015, 2:42 PM UTC

sgbeal wrote: post #33

avar wrote: post #26

Earlier quoted context omitted.

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

> Why do you feel that you _have_ to be able to correct history?

We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history.

The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux kernel), with a dozen or more small commits which the developer did while working on that feature, each of which most likely has just some nonsense text as the commit message.

If you really see the value of preserving every single individual step which the developer has taken, you should record every keystroke, so that you capture every mistake and typo and all the intermediary states of the source code. Or go even further and record every conversation, meeting and all the coffee breaks chats which may or may not be relevant to the feature the developers are just now working on.

Re: Fossil SCM keeps more than just your code

#57

Post by kabdib » Tue, Dec 15, 2015, 2:43 PM UTC

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…

You can always rewrite history, just do a replay into a snapshot of the repository (modifying the system time, or noodling the app to inject the timestamps you want).

I guess you could arrange for some trusted external time authority to sign hashes of commits. That'd be interesting.

Re: Fossil SCM keeps more than just your code

#58

Post by rbehrends » Tue, Dec 15, 2015, 2:44 PM UTC

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…

> In my books its a minus that you can not rewrite history.

To quote Richard Hipp, the primary author of Fossil and SQLite [1]:

"Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs."

About DO-178B: https://en.wikipedia.org/wiki/DO-178B

In short: Fossil is designed for a different purpose than Git.

Note that even then, in Fossil – as with every system that represents data in purely electronic format – nothing is truly immutable. And Fossil does have ways to excise data from history (shunning, "fossil purge", etc.). You can even run raw SQL queries on the underlying SQLite database if you want or use "fossil deconstruct/reconstruct" to break down a repository into its constituent artifacts and rebuild it. However, these are generally methods of last resort and there are no frontend facilities to easily integrate them into your workflow (other than, arguably, "fossil purge", which is local only).

[1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...

Re: Fossil SCM keeps more than just your code

#59

Post by avar » Tue, Dec 15, 2015, 2:59 PM UTC

sgbeal wrote: post #33

avar wrote: post #26

Earlier quoted context omitted.

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

I'll reply to both this and your downstream comment here for simplicity.

    > Why do you feel that you _have_ to be able to
    > correct history? The past is immutable. Fossil
    > treats it as such.

Opinions differ on what aspect of the past should be made immutable.

Should we be recording every single one of your keystrokes in a commit?

How about just every time you hit "save" in your editor?

Git takes the view that making commits is just like hitting "save" in your editor, it's not inherently an operation you want to publish as-is.

You can just as well do this with fossil, whatever the tool's guarantees of immutability I can always just cp an older version of the directory to get around it and re-do my commits, which on some level is exactly what "git rebase" is doing.

Git just makes this process that people have a good reason to do more convenient. Just like I don't want to see every single one of your keystrokes or every one of your "save" snapshots when reviewing your code I have no reason to be reading hundreds of your "oops, compilation error" commits.

Of course I suspect that you don't get much of that with Fossil in the first place, because due to this idealism of immutable history people just aren't using the SCM except for "real" work.

Which I think sucks, Git has saved me multiple times with some bug I've introduced mid-editing session because I could bisect my 100 "another snapshot" commits, commits that I then subsequently rebased into 1-5 commits and pushed upstream.

    > Git allows the public record to be flexible forever.

This is just not at all the case in practice. With Git the difficulty of rewriting history increases as a function of how widely that history is published. Fossil proponents seem to think that established history is being regularly willy-nilly written by projects that use Git.

The mainline history of git.git, or linux-2.6.git etc. is not being rewritten and never will.

What is being rewritten is locally authored commits that haven't been pushed yet, or topic branches that get deleted and replaced by other versions (e.g. with typos fixed in commit messages etc.).

You can use Git like Fossil, but most people just choose not to because it doesn't make sense.

Re: Fossil SCM keeps more than just your code

#60

Post by node_uzer » Tue, Dec 15, 2015, 2:59 PM UTC

I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I've customized the "fossil ui" to my liking.

However, fossil does lacks some important features that svn, hg and git have:

* Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address.

* Cannot perform a "fossil diff" for just a directory and its descendants - i.e., no fossil equivalent of the following:

    # produce a diff for this directory and its descendants
    git diff .

* A "fossil merge" between distributed repos it will give commit attribution to the wrong user for all files in the merge - changes will be recorded as being made by the user performing the merge. This is particularly annoying because it makes "fossil blame" on a given file less effective when pinpointing who introduced what change.

There are other fossil issues, but those are the biggest ones that come to mind.