4 ms·

Mongrel2 is now officially on Github

29 points by alexgartrell 15y ago

alexgartrell 15y ago
Zed's announcement http://twitter.com/#!/zedshaw/status/71988181616177152 http://twitter.com/#!/zedshaw/status/71988181616177152
swah 15y ago
If this was non-trivial its because Zed has been using Fossil SCM for his projects.
jnoller 15y ago
The official blog post of why: http://news.ycombinator.com/item?id=2571499 http://news.ycombinator.com/item?id=2571499
- jlouis 15y ago
  Interestingly, things like this won't happen with the git repository model because it is persistent. New commits doesn't overwrite the old commits in the repo in any way, so you can always get back to a known state. The only destructive packing operation takes great care in making sure it has stable storage before deleting stuff. No, it doesn't save you from a dead disk, but at least you can at any time ask for the consistency of the repository. And finally, it is good to see Zed learning from the experience :)
  - dchest 15y ago
    What do you mean by "persistent"? Unlike Git, in Fossil you cannot rewrite history _at all_. It's an immutable collection of artifacts. There's no rebase. See http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.... Zed lost his working copy. You can do this in git by running "git reset --hard".
    - ollysb 15y ago
      git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.
      - dchest 15y ago
        Working copy
    - j_baker 15y ago
      You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993 http://hackerne.ws/item?id=2524993
      - dchest 15y ago
        It depends on what you mean by "history". Moving refs around is already "modifying history" in Fossil world.
        j_baker 15y ago
        I don't care what Fossil considers rewriting history. Rewriting history means altering a commit that has taken place in the past, which git can't do.
        dchest 15y ago
        What about branches? Tags? Git's fast-forward? Some people think of the whole DAG as history.
        jlouis 15y ago
        Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default. Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible. Fast forward is the recognition that a stick-it-note can be moved linearly ahead. You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.
  - lrm242 15y ago
    From reading the mailing list thread, he didn't lose committed work. He lost uncommitted work. He told fossil to revert everything. I have no dog in this hunt, but I think its important to read the mailing list thread. There you can see people asking if he lost committed vs. non-committed changes. From this message, emphasis mine: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04686.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... fossil revert -- This is what destroyed my work. They were *uncommitted changes*, so once I did this they were gone. I didn't realize it'd nuke them until it was too late.
    - jlouis 15y ago
      Interesting. Because git doesn't protect you from that happening at all either :) It is a situation where shoot-yourself-in-foot is definitely possible.
      - irahul 15y ago
        hg does and I think git should do it as well. `hg revert file.py` creates a file.py.orig where file.py is being reverted. It does creates an extra file which you don't want but it's better in the cases where you accidentally reverted. `hg purge` purges all files not tracked by mercurial and `hg rever --no-backup file.py` can be used when you don't want backup. Considering its usefulness, I am happy to put up with untracked, original file it creates which I don't need most of the times; but boy is it a lifesaver when I do need it.
      - zedshaw 15y ago
        Wrong on both counts. Git's bizarre contrarian UI has screwed up many a repository. I can't tell you how many times some dude's weird "workflow" he decided was the best screwed everyone else on the project over. In this case with fossil, the bug tied my hands so that the only way I could get the code back was to revert. It was a choice between trying to reverse engineer my original uncommitted work or revert and at least try to recover the repo. Since I don't work on more than one thing at once reverting was the best choice.
molecule 15y ago
bloody hell, Zed beat me to the punchline in the first words of the announcement. Well done all around.

29 points by alexgartrell 15y ago

Zed's announcement http://twitter.com/#!/zedshaw/status/71988181616177152 http://twitter.com/#!/zedshaw/status/71988181616177152

swah 15y ago

If this was non-trivial its because Zed has been using Fossil SCM for his projects.

jnoller 15y ago

The official blog post of why: http://news.ycombinator.com/item?id=2571499 http://news.ycombinator.com/item?id=2571499

jlouis 15y ago
Interestingly, things like this won't happen with the git repository model because it is persistent. New commits doesn't overwrite the old commits in the repo in any way, so you can always get back to a known state. The only destructive packing operation takes great care in making sure it has stable storage before deleting stuff. No, it doesn't save you from a dead disk, but at least you can at any time ask for the consistency of the repository. And finally, it is good to see Zed learning from the experience :)
- dchest 15y ago
  What do you mean by "persistent"? Unlike Git, in Fossil you cannot rewrite history _at all_. It's an immutable collection of artifacts. There's no rebase. See http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.... Zed lost his working copy. You can do this in git by running "git reset --hard".
  - ollysb 15y ago
    git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.
    - dchest 15y ago
      Working copy
  - j_baker 15y ago
    You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993 http://hackerne.ws/item?id=2524993
    - dchest 15y ago
      It depends on what you mean by "history". Moving refs around is already "modifying history" in Fossil world.
      - j_baker 15y ago
        I don't care what Fossil considers rewriting history. Rewriting history means altering a commit that has taken place in the past, which git can't do.
        dchest 15y ago
        What about branches? Tags? Git's fast-forward? Some people think of the whole DAG as history.
        jlouis 15y ago
        Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default. Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible. Fast forward is the recognition that a stick-it-note can be moved linearly ahead. You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.
- lrm242 15y ago
  From reading the mailing list thread, he didn't lose committed work. He lost uncommitted work. He told fossil to revert everything. I have no dog in this hunt, but I think its important to read the mailing list thread. There you can see people asking if he lost committed vs. non-committed changes. From this message, emphasis mine: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04686.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... fossil revert -- This is what destroyed my work. They were *uncommitted changes*, so once I did this they were gone. I didn't realize it'd nuke them until it was too late.
  - jlouis 15y ago
    Interesting. Because git doesn't protect you from that happening at all either :) It is a situation where shoot-yourself-in-foot is definitely possible.
    - irahul 15y ago
      hg does and I think git should do it as well. `hg revert file.py` creates a file.py.orig where file.py is being reverted. It does creates an extra file which you don't want but it's better in the cases where you accidentally reverted. `hg purge` purges all files not tracked by mercurial and `hg rever --no-backup file.py` can be used when you don't want backup. Considering its usefulness, I am happy to put up with untracked, original file it creates which I don't need most of the times; but boy is it a lifesaver when I do need it.
    - zedshaw 15y ago
      Wrong on both counts. Git's bizarre contrarian UI has screwed up many a repository. I can't tell you how many times some dude's weird "workflow" he decided was the best screwed everyone else on the project over. In this case with fossil, the bug tied my hands so that the only way I could get the code back was to revert. It was a choice between trying to reverse engineer my original uncommitted work or revert and at least try to recover the repo. Since I don't work on more than one thing at once reverting was the best choice.

molecule 15y ago

bloody hell, Zed beat me to the punchline in the first words of the announcement. Well done all around.