5 ms·

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

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.

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.