6 ms·

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

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 lightweight ticketing system etc., than one system which does it all.

jimktrains2 11y ago
> 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.
- feld 11y ago
  This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.
  - w_t_payne 11y ago
    The user interface is a separate concern from the serialisation format.
  - jimktrains2 11y ago
    1) I never even mentioned a UI or how the user would interact with what I proposed. 2) Even if you just edited files with a text editor, how is that not user friendly? It's about as friendly as it could possibly be.
- WorldMaker 11y ago
  The benefit to having it in the same branch/associated with a specific branch of code is that it makes it easier to have those issues and notes represent the current state of that branch and as you merge branches for that information to similar flow across the merges just as with the associated code. For example, say you fix a bug in a specific branch. If the issue is being tracked inside that branch you can mark it as fixed in that branch, and then checking if an issue is fixed in a given branch is a matter of checking the issue state for that branch. As you merge that code change to other branches, the flag that the issue has been fixed presumably flows with the merge as well and you have an easier time of telling the particular state of any given branch.
jordigh 11y ago
> In my books its a minus that you can not rewrite history. Yeah. Here Mercurial has a very good idea. It records which commits are public and immutable and which commits are drafts and editable. A draft becomes immutable once published, but public commits can always go back to being drafts with a --force, incurring an "everyone out of the pool" scenario. There's nothing wrong with rewriting commits as long as everyone agrees where the boundary lies between published history and drafts. For git, this boundary is often set by a convention such as this: rewrite feature branches all you want, but master must never be rewritten.
ibmthrowaway271 11y ago
> 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.
- thecatspaw 11y ago
  Yes, but then you are fighting the software, and it wouldnt need to be immutable at all if you can change it anyway
- sgbeal 11y ago
  > 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.
  - pdw 11y ago
    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.
    - sgbeal 11y ago
      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.
  - 11y ago
panic 11y ago
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 http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki
- masklinn 11y ago
  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)
  - krupan 11y ago
    Right. You can also "purge" private branches: http://fossil-scm.org/xfer/doc/trunk/www/private.wiki http://fossil-scm.org/xfer/doc/trunk/www/private.wiki It's interesting how both Fossil and Mercurial (and others?) first took strong stances against "changing history" and then softened those stances over time.
  - wyoung2 11y ago
    Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose. Fossil's shun operation and private branches are entirely different from rebasing. First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and if you do the shun on a central repo, any clones of it that were made before the shun don't copy the shun record, so they keep their local copies of the shunned artifact. The only way to propagate a shunning operation through a clone network is cooperatively: you have to ask everyone to agree to shun that artifact in their local clones, then rebuild their repositories. As for private branches being a "history rewriting" mechanism, that's nonsense. Changes made to a private branch are never part of the history on the repo you cloned from in the first place. They're analogous to the default working mode of Git, where your checkins aren't immediately sync'd to the repo you cloned from. If you never sync, or you purge your local changes, history doesn't get rewritten, the changes just never become part of the official history in the first place.
krupan 11y ago
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 http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki
- w_t_payne 11y ago
  Yeah ... the key here is the qualifier "local".
kabdib 11y ago
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.
rbehrends 11y ago
> 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 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.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...

jimktrains2 11y ago

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

feld 11y ago
This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.
- w_t_payne 11y ago
  The user interface is a separate concern from the serialisation format.
- jimktrains2 11y ago
  1) I never even mentioned a UI or how the user would interact with what I proposed. 2) Even if you just edited files with a text editor, how is that not user friendly? It's about as friendly as it could possibly be.
WorldMaker 11y ago
The benefit to having it in the same branch/associated with a specific branch of code is that it makes it easier to have those issues and notes represent the current state of that branch and as you merge branches for that information to similar flow across the merges just as with the associated code. For example, say you fix a bug in a specific branch. If the issue is being tracked inside that branch you can mark it as fixed in that branch, and then checking if an issue is fixed in a given branch is a matter of checking the issue state for that branch. As you merge that code change to other branches, the flag that the issue has been fixed presumably flows with the merge as well and you have an easier time of telling the particular state of any given branch.

jordigh 11y ago

> In my books its a minus that you can not rewrite history. Yeah. Here Mercurial has a very good idea. It records which commits are public and immutable and which commits are drafts and editable. A draft becomes immutable once published, but public commits can always go back to being drafts with a --force, incurring an "everyone out of the pool" scenario. There's nothing wrong with rewriting commits as long as everyone agrees where the boundary lies between published history and drafts. For git, this boundary is often set by a convention such as this: rewrite feature branches all you want, but master must never be rewritten.

ibmthrowaway271 11y ago

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

thecatspaw 11y ago
Yes, but then you are fighting the software, and it wouldnt need to be immutable at all if you can change it anyway
sgbeal 11y ago
> 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.
- pdw 11y ago
  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.
  - sgbeal 11y ago
    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.
- 11y ago

panic 11y ago

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 http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki

masklinn 11y ago
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)
- krupan 11y ago
  Right. You can also "purge" private branches: http://fossil-scm.org/xfer/doc/trunk/www/private.wiki http://fossil-scm.org/xfer/doc/trunk/www/private.wiki It's interesting how both Fossil and Mercurial (and others?) first took strong stances against "changing history" and then softened those stances over time.
- wyoung2 11y ago
  Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose. Fossil's shun operation and private branches are entirely different from rebasing. First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and if you do the shun on a central repo, any clones of it that were made before the shun don't copy the shun record, so they keep their local copies of the shunned artifact. The only way to propagate a shunning operation through a clone network is cooperatively: you have to ask everyone to agree to shun that artifact in their local clones, then rebuild their repositories. As for private branches being a "history rewriting" mechanism, that's nonsense. Changes made to a private branch are never part of the history on the repo you cloned from in the first place. They're analogous to the default working mode of Git, where your checkins aren't immediately sync'd to the repo you cloned from. If you never sync, or you purge your local changes, history doesn't get rewritten, the changes just never become part of the official history in the first place.

krupan 11y ago

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 http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki

w_t_payne 11y ago
Yeah ... the key here is the qualifier "local".

kabdib 11y ago

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.

rbehrends 11y ago

> 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 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.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...