4 ms·

> but at that point we're re-inventing subversion So? Maybe Subversion is all most developers need?

by pan69 4y ago

dalyons 4y ago
Solo devs maybe. Merging and branching are so much worse in svn that it’s not good enough for “most developers”, aka those working on professional projects with a team of developers. Sure we used to make do with svn, but I have no desire to go back.
- mnd999 4y ago
  Honestly I’d take CVS over subversion. Merging was just bad on subversion and I found the IDE integrations to be confusing, obtuse and buggy. Sure, CVS was limited but it was reliable and straightforward.
  - DonHopkins 4y ago
    ...And better than SCCS! ;)
  - johannes1234321 4y ago
    > Sure, CVS was limited but it was reliable and straightforward. It was so reliable that people complained about SVN using a DB (Berkeley DB) as backend, as manual fixing of CVS files was a "normal" part of operation and people didn't believe that might not be needed ...
- avgcorrection 4y ago
  > Solo devs maybe. Like I’m gonna bother to set up a Subversion remote for every little repo that I create for myself.
  - theamk 4y ago
    The most beautiful part of svn, and the one I miss the most in git, is the fact that there is no need to set up tons of separate repo. Every subdirectory acts as a separate git repo. This means you usually only have one svn repo, and you set it up the way you like. As an example, you may set things up so you can checkout: server:/proj/small/hello - to get a single project server:/proj/small- to get all small projects server:/proj - to get all projects If you already have one of those checked out, adding new project is as simple as "mkdir bar", "svn add bar", "svn commit". So juch easier than making new github repo. And multi-level hierarchical project nesting is still something impossible in git.
    - avgcorrection 4y ago
      > So juch easier than making new github repo. Were you paying attention to what I just wrote!? `git init`. What do I need a remote on the Internet for?
      - theamk 4y ago
        Don't you ever share your projects between machines? I at least have laptop, a desktop, and occasional raspberry pi. An ability to have personal projects on both is very handy. It also acts as a nice backup. But yes, if all your work is on one machine, and you have backups of it, there is not much point in svn.
        avgcorrection 4y ago
        That’s a file sync. problem, not a VCS problem. And backup is a separate problem.
      - Rexxar 4y ago
        You don't need internet, you can create the main repo somewhere else on your pc (preferably on a second disk to have very minimal backup) and you use file url to access it "file:///F:/MyRepositoriesAreHere/MyProject-repo/ProjectName/trunk"
        avgcorrection 4y ago
        That’s better but still an extra step.
- Falkon1313 4y ago
  Odd, I found branching and merging so much easier in SVN. Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN. And rebasing a branch with several commits can be a nightmare since you have to re-merge almost (but not exactly) the same code over and over again at whatever state it was in at some time in the past when some previous commit happened - unless you abort out and squash first. In SVN, you just merged the whole branch once and when both were in their final current state. Of course, git's a lot more powerful, but with that comes complexity. SVN branching and merging was a snap comparatively.
  - kevin_thibedeau 4y ago
    SVN will frequently insist that merge conflicts exist where there shouldn't be any if trees have been modified by deleting or moving directories. This is so pervasive that organizations will avoid doing merges because of the manual fixups you have to do on long lived branches. There's metadata now for tracking branch history but older versions couldn't figure out that two branches in a merge had a common ancestor. A puzzling thing to omit from a VCS.
    - COMMENT___ 4y ago
      AFAIK, conflict resolution in Subversion is being improved: * https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver https://subversion.apache.org/docs/release-notes/1.10.html#c... * https://subversion.apache.org/docs/release-notes/1.11.html#conflict-resolver https://subversion.apache.org/docs/release-notes/1.11.html#c...
  - Izkata 4y ago
    > Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN. I mean, if that's a reason to say git doesn't technically have branches, then neither does svn. It has subdirectories that you can make copies of at any level, and copy commits between them at any level, such that you can make an amazing repo-within-a-repo mess not possible in git.
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.
abirch 4y ago
I loved this XKCD. https://xkcd.com/1597/ https://xkcd.com/1597/ use these commands unless you get an error, then save your changes, and download a fresh copy.
oneplane 4y ago
In which case they can use Subversion. Or Dropbox since it essentially offers the same features. I don't think there is anything bad about it, just that it solves different problems. Older systems like CVS are also still in use, but it appears that none of the old systems really lasted more broadly and aren't useful for the needs of today.

> but at that point we're re-inventing subversion So? Maybe Subversion is all most developers need?

by pan69 4y ago

> but at that point we're re-inventing subversion So? Maybe Subversion is all most developers need?

Solo devs maybe. Merging and branching are so much worse in svn that it’s not good enough for “most developers”, aka those working on professional projects with a team of developers. Sure we used to make do with svn, but I have no desire to go back.

mnd999 4y ago
Honestly I’d take CVS over subversion. Merging was just bad on subversion and I found the IDE integrations to be confusing, obtuse and buggy. Sure, CVS was limited but it was reliable and straightforward.
- DonHopkins 4y ago
  ...And better than SCCS! ;)
- johannes1234321 4y ago
  > Sure, CVS was limited but it was reliable and straightforward. It was so reliable that people complained about SVN using a DB (Berkeley DB) as backend, as manual fixing of CVS files was a "normal" part of operation and people didn't believe that might not be needed ...
avgcorrection 4y ago
> Solo devs maybe. Like I’m gonna bother to set up a Subversion remote for every little repo that I create for myself.
- theamk 4y ago
  The most beautiful part of svn, and the one I miss the most in git, is the fact that there is no need to set up tons of separate repo. Every subdirectory acts as a separate git repo. This means you usually only have one svn repo, and you set it up the way you like. As an example, you may set things up so you can checkout: server:/proj/small/hello - to get a single project server:/proj/small- to get all small projects server:/proj - to get all projects If you already have one of those checked out, adding new project is as simple as "mkdir bar", "svn add bar", "svn commit". So juch easier than making new github repo. And multi-level hierarchical project nesting is still something impossible in git.
  - avgcorrection 4y ago
    > So juch easier than making new github repo. Were you paying attention to what I just wrote!? `git init`. What do I need a remote on the Internet for?
    - theamk 4y ago
      Don't you ever share your projects between machines? I at least have laptop, a desktop, and occasional raspberry pi. An ability to have personal projects on both is very handy. It also acts as a nice backup. But yes, if all your work is on one machine, and you have backups of it, there is not much point in svn.
      - avgcorrection 4y ago
        That’s a file sync. problem, not a VCS problem. And backup is a separate problem.
    - Rexxar 4y ago
      You don't need internet, you can create the main repo somewhere else on your pc (preferably on a second disk to have very minimal backup) and you use file url to access it "file:///F:/MyRepositoriesAreHere/MyProject-repo/ProjectName/trunk"
      - avgcorrection 4y ago
        That’s better but still an extra step.
Falkon1313 4y ago
Odd, I found branching and merging so much easier in SVN. Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN. And rebasing a branch with several commits can be a nightmare since you have to re-merge almost (but not exactly) the same code over and over again at whatever state it was in at some time in the past when some previous commit happened - unless you abort out and squash first. In SVN, you just merged the whole branch once and when both were in their final current state. Of course, git's a lot more powerful, but with that comes complexity. SVN branching and merging was a snap comparatively.
- kevin_thibedeau 4y ago
  SVN will frequently insist that merge conflicts exist where there shouldn't be any if trees have been modified by deleting or moving directories. This is so pervasive that organizations will avoid doing merges because of the manual fixups you have to do on long lived branches. There's metadata now for tracking branch history but older versions couldn't figure out that two branches in a merge had a common ancestor. A puzzling thing to omit from a VCS.
  - COMMENT___ 4y ago
    AFAIK, conflict resolution in Subversion is being improved: * https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver https://subversion.apache.org/docs/release-notes/1.10.html#c... * https://subversion.apache.org/docs/release-notes/1.11.html#conflict-resolver https://subversion.apache.org/docs/release-notes/1.11.html#c...
- Izkata 4y ago
  > Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN. I mean, if that's a reason to say git doesn't technically have branches, then neither does svn. It has subdirectories that you can make copies of at any level, and copy commits between them at any level, such that you can make an amazing repo-within-a-repo mess not possible in git.

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.

abirch 4y ago

I loved this XKCD. https://xkcd.com/1597/ https://xkcd.com/1597/ use these commands unless you get an error, then save your changes, and download a fresh copy.

oneplane 4y ago

In which case they can use Subversion. Or Dropbox since it essentially offers the same features. I don't think there is anything bad about it, just that it solves different problems. Older systems like CVS are also still in use, but it appears that none of the old systems really lasted more broadly and aren't useful for the needs of today.