6 ms·

Sane revision numbers are among the many reasons I prefer SVN to GIT.

by gyulai 4y ago

jstimpfle 4y ago
You could automatically tag each uploaded commit with a number drawn from a sequence - using a git post-update hook. The only problem is that this centralizes the process. It's not possible to have fully "blessed" commits without pushing them first. And that's how SVN works, too.
- loeg 4y ago
  For local repositories, you can do it as a post-commit hook. In the hook: prefix=whatever old=$(git rev-parse HEAD) new=$(brute force $prefix) git update-ref -m "chose prefix $prefix" --create-reflog HEAD "$new" Of course, it's pretty silly and slow.
MAGZine 4y ago
... What are the other reasons?
- gyulai 4y ago
  Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff." They'll either laugh you out of the room or you'll be in trouble with the Department of Temporal Investigations for polluting the time line, because what we currently understand as git sure as hell won't be the design they'll come up with. So for me: I prefer centralized. And SVN is just a reasonable one to use.
  - breck 4y ago
    Oh we use distributed day in and day out for everything. Once you start battling censorship you’ll get it.
    - gyulai 4y ago
      ...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone, not just the one-percenters).
      - seniorThrowaway 4y ago
        the mental model is hard for so many people precisely because all they know of git is github
      - breck 4y ago
        Fair point! I would love to use the Extremely Linear Git History of the parent post. I actually wrote a new layer on top of Git years ago (I called it git4 IIRC) and I pitched it to both GitHub and GitLab but they ignored it. I guess I should have pitched it to the mailing list. I think I was too afraid it was dumb. Will do that at some point.
      - detaro 4y ago
        That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Or maybe it's not as binary, and Gits model with its complexity has more useful properties making the trade off worth it.
        gyulai 4y ago
        > That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Computing history is full of examples where technologies that are objectively not the best technologies end up being dominant. It's more about economics. (Network externalities, switching costs, ...) Although I will admit that, with version control, there isn't even an alternative out there that is anything like an "objective winner". Each one has its problems, and it's a matter of choosing the least of the evils. -- I haven't tried any of the commercial ones though.

Sane revision numbers are among the many reasons I prefer SVN to GIT.

by gyulai 4y ago

Sane revision numbers are among the many reasons I prefer SVN to GIT.

You could automatically tag each uploaded commit with a number drawn from a sequence - using a git post-update hook. The only problem is that this centralizes the process. It's not possible to have fully "blessed" commits without pushing them first. And that's how SVN works, too.

loeg 4y ago
For local repositories, you can do it as a post-commit hook. In the hook: prefix=whatever old=$(git rev-parse HEAD) new=$(brute force $prefix) git update-ref -m "chose prefix $prefix" --create-reflog HEAD "$new" Of course, it's pretty silly and slow.

MAGZine 4y ago

... What are the other reasons?

gyulai 4y ago
Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff." They'll either laugh you out of the room or you'll be in trouble with the Department of Temporal Investigations for polluting the time line, because what we currently understand as git sure as hell won't be the design they'll come up with. So for me: I prefer centralized. And SVN is just a reasonable one to use.
- breck 4y ago
  Oh we use distributed day in and day out for everything. Once you start battling censorship you’ll get it.
  - gyulai 4y ago
    ...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone, not just the one-percenters).
    - seniorThrowaway 4y ago
      the mental model is hard for so many people precisely because all they know of git is github
    - breck 4y ago
      Fair point! I would love to use the Extremely Linear Git History of the parent post. I actually wrote a new layer on top of Git years ago (I called it git4 IIRC) and I pitched it to both GitHub and GitLab but they ignored it. I guess I should have pitched it to the mailing list. I think I was too afraid it was dumb. Will do that at some point.
    - detaro 4y ago
      That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Or maybe it's not as binary, and Gits model with its complexity has more useful properties making the trade off worth it.
      - gyulai 4y ago
        > That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Computing history is full of examples where technologies that are objectively not the best technologies end up being dominant. It's more about economics. (Network externalities, switching costs, ...) Although I will admit that, with version control, there isn't even an alternative out there that is anything like an "objective winner". Each one has its problems, and it's a matter of choosing the least of the evils. -- I haven't tried any of the commercial ones though.