6 ms·

I use SVN at my job and I gotta say I kind of prefer it to Git. Feels much lighter and the commands make a lot more sense to me

alkonaut 6y ago
That is until you start branching and merging a lot. If you just develop on trunk and basically only do update and commit, then of course svn is more ergonomic. The problem is all the drawbacks of trunk based development: difficult code reviews, no gating so trunk build can break.
- CraigJPerry 6y ago
  >> 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.
zadokshi 6y ago
Yep, SVN is simpler and easier for single developer / simplistic projects. GIT is much easier for larger multi developer concurrent development. I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)
- studius 6y ago
  Git is actually simpler, here's why: No central server to setup or required, period. Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them. Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts. Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?
  - oblio 6y ago
    > Git is actually simpler, here's why: > No central server to setup or required, period. I've never seen a company work like this, though.
    - panpanna 6y ago
      Oh, you would be surprised how common this is. If you don't need access control, it's the easiest way to get started with source control for small teams
  - zorpner 6y ago
    > No central server to setup or required, period. Someone should let every single person and organization that uses git know about this!
    - corty 6y ago
      Maybe, maybe not. As a developer I love that git gives me the ability to create my own repo anywhere on any machine, just with git installed. Repos can be synced and patches exchanged in numerous ways and any decentral copy is a full backup of everything. But as someone having worked in larger companies, there are huuge red flags with this that you wouldn't want the wrong people in your company to know about. Fully functional repos anywhere means central control is impossible. You can't just limit access in any meaningful way, you can't control info leaks, if someone can carry out a git clone on an USB stick. And full repo with history means that you always know everything about the work performance of all colleagues, past and present.
pulse7 6y ago
SVN is also better at handling (large) repos with (large) binary files than GIT. So if you decide to store your scanned business documents in a version control system SVN is a better solution than GIT. So I use GIT for software projects and SVN for business documents.
- SEJeff 6y ago
  Indeed. Subversion stores history on a per-file basis and not a per-project basis. This is one of the precious few areas where Subversion does best git.
  - adrianmsmith 6y ago
    > Subversion stores history on a per-file basis and not a per-project basis. I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”. Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
    - SEJeff 6y ago
      No, I mean in the on disk format, the history is stored per-file. This is why svn blame is massively faster than git blame, because git blame has to go through history for all files to find the right bits whereas svn does not. The svn file format vs the git pack format are very very different on-disk.
      - alblue 6y ago
        That only works when your SVN server is in the same computer as you; the fact that SVN has to reach out to get additional data for the history is what kills it. With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using. In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.
hannob 6y ago
I used to think like that, but have eventually given up. SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.
kergonath 6y ago
I prefer git’s model but you’re right; git commands don’t make any sense. Simple things (push, pull, commit, etc) are simple enough but it gets very quickly quite difficult to use without looking up a similar case on Stack Overflow.
- coldpie 6y ago
  They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but it's good enough and some tools just require training to use effectively.
  - User23 6y ago
    It takes about an hour to read and understand that documentation and I highly recommend doing so. And once you do git becomes far more intuitive. The key concepts to understand are commits and refs. To a first approximation a branch is just a variable ref and a tag is a constant ref. A commit is a node in a generally sparse upside down tree and refs are pointers to said nodes. Once one realizes that then pretty much everything makes sense. For example the difference between rebase and merge is how they affect the structure of the commit tree.
    - cnst 6y ago
      To add to that: learn how to use git-reflog. It's the most fantastic thing ever, let's you have a complete control over the local revision history to undo anything you want. I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way). I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
dunce2020 6y ago
I've only ever really used git as a locally hosted SVN.
climb_stealth 6y ago
IMO the best part about SVN is that you can use git-svn to run it through git locally. If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.

alkonaut 6y ago

That is until you start branching and merging a lot. If you just develop on trunk and basically only do update and commit, then of course svn is more ergonomic. The problem is all the drawbacks of trunk based development: difficult code reviews, no gating so trunk build can break.

CraigJPerry 6y ago
>> 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.

zadokshi 6y ago

Yep, SVN is simpler and easier for single developer / simplistic projects. GIT is much easier for larger multi developer concurrent development. I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)

studius 6y ago
Git is actually simpler, here's why: No central server to setup or required, period. Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them. Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts. Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?
- oblio 6y ago
  > Git is actually simpler, here's why: > No central server to setup or required, period. I've never seen a company work like this, though.
  - panpanna 6y ago
    Oh, you would be surprised how common this is. If you don't need access control, it's the easiest way to get started with source control for small teams
- zorpner 6y ago
  > No central server to setup or required, period. Someone should let every single person and organization that uses git know about this!
  - corty 6y ago
    Maybe, maybe not. As a developer I love that git gives me the ability to create my own repo anywhere on any machine, just with git installed. Repos can be synced and patches exchanged in numerous ways and any decentral copy is a full backup of everything. But as someone having worked in larger companies, there are huuge red flags with this that you wouldn't want the wrong people in your company to know about. Fully functional repos anywhere means central control is impossible. You can't just limit access in any meaningful way, you can't control info leaks, if someone can carry out a git clone on an USB stick. And full repo with history means that you always know everything about the work performance of all colleagues, past and present.

pulse7 6y ago

SVN is also better at handling (large) repos with (large) binary files than GIT. So if you decide to store your scanned business documents in a version control system SVN is a better solution than GIT. So I use GIT for software projects and SVN for business documents.

SEJeff 6y ago
Indeed. Subversion stores history on a per-file basis and not a per-project basis. This is one of the precious few areas where Subversion does best git.
- adrianmsmith 6y ago
  > Subversion stores history on a per-file basis and not a per-project basis. I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”. Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
  - SEJeff 6y ago
    No, I mean in the on disk format, the history is stored per-file. This is why svn blame is massively faster than git blame, because git blame has to go through history for all files to find the right bits whereas svn does not. The svn file format vs the git pack format are very very different on-disk.
    - alblue 6y ago
      That only works when your SVN server is in the same computer as you; the fact that SVN has to reach out to get additional data for the history is what kills it. With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using. In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.

hannob 6y ago

I used to think like that, but have eventually given up. SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.

kergonath 6y ago

I prefer git’s model but you’re right; git commands don’t make any sense. Simple things (push, pull, commit, etc) are simple enough but it gets very quickly quite difficult to use without looking up a similar case on Stack Overflow.

coldpie 6y ago
They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but it's good enough and some tools just require training to use effectively.
- User23 6y ago
  It takes about an hour to read and understand that documentation and I highly recommend doing so. And once you do git becomes far more intuitive. The key concepts to understand are commits and refs. To a first approximation a branch is just a variable ref and a tag is a constant ref. A commit is a node in a generally sparse upside down tree and refs are pointers to said nodes. Once one realizes that then pretty much everything makes sense. For example the difference between rebase and merge is how they affect the structure of the commit tree.
  - cnst 6y ago
    To add to that: learn how to use git-reflog. It's the most fantastic thing ever, let's you have a complete control over the local revision history to undo anything you want. I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way). I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.

dunce2020 6y ago

I've only ever really used git as a locally hosted SVN.

climb_stealth 6y ago

IMO the best part about SVN is that you can use git-svn to run it through git locally. If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.