4 ms·

Git makes sense for the Linux kernel and merging patches at scale. 99% of software development would be fine with subversion

by abirch 4y ago

lambda_lord 4y ago
Git completely replaced Subversion so quickly because the benefits were apparent even at a small scale. Subversion was centralized and slow whereas Git branches were cheap and fast. It turns out the distributed model is just a lot better. Even my college project teams benefited from the superior experience of Git.
- bsder 4y ago
  Except that everybody changed to Github not git. And effectively recreated Subversion with caching.
  - dopidopHN 4y ago
    No, I worked with gitlab, bitbucket, custom git server installs in the last 3 years alone.
  - PaulDavisThe1st 4y ago
    "Subversion with caching" is not subversion. I used subversion for a long time and was resistant to moving ardour.org to use git instead. 24hours after we switched (we never use 3rd party git hosting as our canonical repo), I was already convinced it was not the right choice, but an excellent choice.
  - astrange 4y ago
    It's also Subversion where you can commit your changes and write the message before pushing, instead of at the same time, so you get the chance to review it. That's enough to make it better.
- pizza234 4y ago
  Interestingly, there was a distributed SCM build on top of SVN, called SVK (https://wiki.c2.com/?SvkVersionControl https://wiki.c2.com/?SvkVersionControl). Being distributed, it solved the main gripes with SVN; it also added a better merging algorithm (https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf), solving another big gripe. I was actually satisfied of it, and surprised that it never got attention, in particular, because there were no requirements in order to use it with existing SVN repositories. I'm actually baffled, because SVN is still active, so SVK would still be useful nowadays.
  - kevin_thibedeau 4y ago
    May as well use Git SVN integration for this.
dopidopHN 4y ago
Have you use subversion ? If yes, do you remember how slow it was? How cutting a branch and then merge it was seen as something for senior dev to handle ?
- abirch 4y ago
  I did use subversion in college. Never professionally, so creating our own branches wasn't a pain. I think there is a reason why this XKCD was made: https://xkcd.com/1597/ https://xkcd.com/1597/
  - avgcorrection 4y ago
    “Delete your work and clone again” is ridiculous. Just goes to show that you don’t know what you’re talking about (or the xkcd guy for that matter).
    - abirch 4y ago
      I'm talking about my needs, ditto with the XKCD guy. Basically I just need to be able to create a PR from my local changes. Not much more.
pantalaimon 4y ago
Subversion requires a server, so it’s not suitable for the small local one-off repo
- rad_gruchalski 4y ago
  No. It doesn’t. svn checkout file://path/to/repo works absolutely fine.
  - oneplane 4y ago
    But it does need a server to collaborate, doesn't it?
    - rad_gruchalski 4y ago
      Define a server. NFS will be enough for more than one person to use a repo over the file protocol. It will work fine over a Windows share, Samba, NFS, and so on. It doesn’t need svn or http protocol to operate.
      - oneplane 4y ago
        I could define a server but I'm not a dictionary so I won't. SVN doesn't work peer-to-peer or over email. And that's fine. It's just not ready to go with only local tools. Of course, you can use GitHub with Subversion just fine, but that wasn't the point. The point was that Subversion alone is never enough if you want to collaborate.
        rad_gruchalski 4y ago
        > I could define a server but I'm not a dictionary so I won't. That’s a bummer. It would help us point the discussion in the right direction. > SVN doesn't work peer-to-peer or over email. Why not? What is so different about people having their own subversion repositories over file protocol vs people having their git repositories? Why would you not be able to send a subversion patch in an email? As someone who uses git for 10 years, I understand it may not be as ergonomic as with git. But why not? > The point was that Subversion alone is never enough if you want to collaborate. Why not? Is git enough?
avgcorrection 4y ago
Anything can be made to work. But I don’t see why I would want to handicap myself with a truly centralized SCM system. Sure, we use one canonical repository. All our “pull requests” are really merge requests, mostly to the main branch. So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it. The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams? I think that this idea that non-distributed VCS is somehow the default—as in the obvious, simple thing to implement—is just backwards. Of course the default assumption for any VCS operation—unless it has a name like “send-email”—should be that it operates on your own local copy. Sure, we use a centralized repo structure. And the only call-central-command operation I use is “git push”. All the other fiddling and querying—and all the things that make version-control-as-history useful—is local.

Git makes sense for the Linux kernel and merging patches at scale. 99% of software development would be fine with subversion

by abirch 4y ago

Git makes sense for the Linux kernel and merging patches at scale. 99% of software development would be fine with subversion

lambda_lord 4y ago

Git completely replaced Subversion so quickly because the benefits were apparent even at a small scale. Subversion was centralized and slow whereas Git branches were cheap and fast. It turns out the distributed model is just a lot better. Even my college project teams benefited from the superior experience of Git.

bsder 4y ago
Except that everybody changed to Github not git. And effectively recreated Subversion with caching.
- dopidopHN 4y ago
  No, I worked with gitlab, bitbucket, custom git server installs in the last 3 years alone.
- PaulDavisThe1st 4y ago
  "Subversion with caching" is not subversion. I used subversion for a long time and was resistant to moving ardour.org to use git instead. 24hours after we switched (we never use 3rd party git hosting as our canonical repo), I was already convinced it was not the right choice, but an excellent choice.
- astrange 4y ago
  It's also Subversion where you can commit your changes and write the message before pushing, instead of at the same time, so you get the chance to review it. That's enough to make it better.
pizza234 4y ago
Interestingly, there was a distributed SCM build on top of SVN, called SVK (https://wiki.c2.com/?SvkVersionControl https://wiki.c2.com/?SvkVersionControl). Being distributed, it solved the main gripes with SVN; it also added a better merging algorithm (https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf), solving another big gripe. I was actually satisfied of it, and surprised that it never got attention, in particular, because there were no requirements in order to use it with existing SVN repositories. I'm actually baffled, because SVN is still active, so SVK would still be useful nowadays.
- kevin_thibedeau 4y ago
  May as well use Git SVN integration for this.

dopidopHN 4y ago

Have you use subversion ? If yes, do you remember how slow it was? How cutting a branch and then merge it was seen as something for senior dev to handle ?

abirch 4y ago
I did use subversion in college. Never professionally, so creating our own branches wasn't a pain. I think there is a reason why this XKCD was made: https://xkcd.com/1597/ https://xkcd.com/1597/
- avgcorrection 4y ago
  “Delete your work and clone again” is ridiculous. Just goes to show that you don’t know what you’re talking about (or the xkcd guy for that matter).
  - abirch 4y ago
    I'm talking about my needs, ditto with the XKCD guy. Basically I just need to be able to create a PR from my local changes. Not much more.

pantalaimon 4y ago

Subversion requires a server, so it’s not suitable for the small local one-off repo

rad_gruchalski 4y ago
No. It doesn’t. svn checkout file://path/to/repo works absolutely fine.
- oneplane 4y ago
  But it does need a server to collaborate, doesn't it?
  - rad_gruchalski 4y ago
    Define a server. NFS will be enough for more than one person to use a repo over the file protocol. It will work fine over a Windows share, Samba, NFS, and so on. It doesn’t need svn or http protocol to operate.
    - oneplane 4y ago
      I could define a server but I'm not a dictionary so I won't. SVN doesn't work peer-to-peer or over email. And that's fine. It's just not ready to go with only local tools. Of course, you can use GitHub with Subversion just fine, but that wasn't the point. The point was that Subversion alone is never enough if you want to collaborate.
      - rad_gruchalski 4y ago
        > I could define a server but I'm not a dictionary so I won't. That’s a bummer. It would help us point the discussion in the right direction. > SVN doesn't work peer-to-peer or over email. Why not? What is so different about people having their own subversion repositories over file protocol vs people having their git repositories? Why would you not be able to send a subversion patch in an email? As someone who uses git for 10 years, I understand it may not be as ergonomic as with git. But why not? > The point was that Subversion alone is never enough if you want to collaborate. Why not? Is git enough?

avgcorrection 4y ago

Anything can be made to work. But I don’t see why I would want to handicap myself with a truly centralized SCM system. Sure, we use one canonical repository. All our “pull requests” are really merge requests, mostly to the main branch. So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it. The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams? I think that this idea that non-distributed VCS is somehow the default—as in the obvious, simple thing to implement—is just backwards. Of course the default assumption for any VCS operation—unless it has a name like “send-email”—should be that it operates on your own local copy. Sure, we use a centralized repo structure. And the only call-central-command operation I use is “git push”. All the other fiddling and querying—and all the things that make version-control-as-history useful—is local.