3 ms·

>> until you start branching and merging a lot SVN has 3 way merge too so this isn’t the issue it was in other VCS’s >> The problem is all the drawbacks of tr

>> until you start branching and merging a lot SVN has 3 way merge too so this isn’t the issue it was in other VCS’s >> The problem is all the drawbacks of trunk based development Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc. Ironically these days i see a big push to use git in a way that would work pretty well in svn too. The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride. Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.

jlouis 6y ago
The biggest hassle with svn is adminstrative overhead. You need to give developers access. Git completely works around this hurdle.
- oblio 6y ago
  You still need to give developers access with git. All the companies I've worked for have a blessed git repo which definitely has access control in place.
alkonaut 6y ago
The merge tracking that was tacked onto svn just isn’t reliable. Adding it as metadata isn’t a good enough solution. Shared medium/long lived branches such as version maintenance branches or shared dev branches invariably get merges “both ways” meaning the information of what’s merged where is sprinkled everywhere. But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git. I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.
theamk 6y ago
I have used both SVN and GitHub Enterprise for work, and they are nothing alike. For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached. With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.

jlouis 6y ago

The biggest hassle with svn is adminstrative overhead. You need to give developers access. Git completely works around this hurdle.

oblio 6y ago
You still need to give developers access with git. All the companies I've worked for have a blessed git repo which definitely has access control in place.

alkonaut 6y ago

The merge tracking that was tacked onto svn just isn’t reliable. Adding it as metadata isn’t a good enough solution. Shared medium/long lived branches such as version maintenance branches or shared dev branches invariably get merges “both ways” meaning the information of what’s merged where is sprinkled everywhere. But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git. I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.

theamk 6y ago

I have used both SVN and GitHub Enterprise for work, and they are nothing alike. For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached. With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.