31

I want to choose a version control system for my company. So far I know I have Git, Subversion and Mercurial.

These days I see that Git is the most used, so I'm left wondering: would there be any specific reason to still use Subversion, or should I go directly to Git?

hippietrail
  • 263
  • 3
  • 10
user1179459
  • 1,183
  • 3
  • 13
  • 18
  • 37
    They both work. The important thing is whether they'll meet your requirements, which you haven't told us. – Matthew Flynn Sep 03 '12 at 05:38
  • 6
    See [Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there?](http://stackoverflow.com/q/3215282/188535) on Stack Overflow. – detly Sep 03 '12 at 07:27
  • 11
    On which argument do you exclude Mercurial? – mouviciel Sep 03 '12 at 08:55
  • 1
    @Matthew That’s a bit facile, isn’t it? Lots of things “work” – barely. When choosing a tool the question is *how well* it works. Yes, this depends to some extent on requirements but we *can* give a general assessment. – Konrad Rudolph Sep 03 '12 at 10:30
  • There's a good, balanced answer about this over on SO: http://stackoverflow.com/a/875/9625 – njr101 Sep 03 '12 at 11:19
  • 8
    -1 for subjective (baiting IMHO) wording and "Those days I see that Git is the most used" - citation needed. Git is extremely common in the open source world, but in the corporate space it's _much_ rarer. Corps really like the idea of a single, central, authoritative repository and are very slow to change. In the corporate space you're more likely to see good ole CVS than SVN even, never mind a DVCS. – Keith Sep 03 '12 at 13:31
  • 2
    @Keith that's because the corporate world is always significantly behind the curve (support contracts / security concerns / cost of change). If you're starting a new project you should strive to use the latest tools so when the corporate world finally catches up you don't have to do so much migration work. – Robin Winslow Sep 03 '12 at 14:05
  • 2
    @RobinWinslow you should strive to use the most appropriate tools and to try to avoid using outmoded tools (and I'm not at all sure SVN falls into that category). You shouldn't necessarily be looking at the bleeding edge (latest) in most cases you want to be a step or two behind. – Murph Sep 03 '12 at 14:13
  • 1
    @Murph http://en.wikipedia.org/wiki/Git_(software)#History - only in the development teams of archaic, monolithic companies is software originating in 2005 considered "bleeding edge" – Robin Winslow Sep 03 '12 at 14:19
  • It seems clear to me based on things that have been said in this thread that many of the people posting have likely only used one of the version control systems you mentioned. This has led to people saying a lot of things that really aren't quite true. The biggest advantage to git is that branching and merging is insanely easy in git but is rather involved in svn. There are other finer points that could be debated but depending on your project needs would be irrelevant. (PS I started out with svn and later reluctantly started using git and now prefer git) – Kenneth Sep 03 '12 at 14:39
  • 1
    @RobinWinslow, I think you underestimate how long it takes for a new idea to become widely accepted and to be labeled the "bleeding Edge." For example, I started hearing about Python as the awesome new replacement for Perl in the mid 2000's. A lot of people heard about Python at the same time. Problem is that Python was released in *1991*. It was well over a decade old and people were calling the "cool new scripting language." Don't underestimate how long it takes for new technologies to settle down. – riwalk Sep 03 '12 at 18:51
  • 1
    Having persuaded the rest of my team (in a fairly bureaucratic corporate environment) to switch from SVN to Git, I don't think there are any reasons to keep SVN around. One of the benefits of Git is that people lose the fear of committing, branching, merging, etc. because there is another layer between them and the central repo. If you mess up a merge, commit the wrong things, whatever, you just reset to an earlier commit and get back to work. Once you commit to SVN everyone sees it. I used SVN and enjoyed it for awhile, but there are better tools now. – Kryptic Sep 04 '12 at 01:42
  • 2
    @RobinWinslow true, corp is risk-averse and slow to change. However there's some things they're never going to stop wanting and that Git doesn't do, like the ability to audit code changes (i.e. a log that can never be edited to change history) or have one branch/fork that's absolutely the 'gospel' copy of the code. I doubt many will ever move to Git for that reason, though they may consider other DVCS (such as Veracity) that do support what they need. – Keith Sep 04 '12 at 06:45
  • @Keith this is an ignorant reason for not wanting to use Git. There is absolutely nothing in Git to stop you having a canonical repository - that's what the `origin` remote standard practice is for. Almost everyone who has ever used Git has had a canonical repository somewhere (e.g. https://github.com/). It can do that for you, and still you can use source control without being able to access the remote repository when you need to, and it won't mess up your merges like SVN always does. – Robin Winslow Sep 04 '12 at 06:58
  • @Kryptic, you aren't in a bureaucratic environment. We switched VCS a few years ago, nobody in the development organisation was involved, it was considered an operation responsibility. At least what they presented us showed that git was at least considered even if rejected. – AProgrammer Sep 04 '12 at 06:59
  • 2
    @RobinWinslow - you're talking about best-practice, corporations want _enforceable_. As for "mess up your merges" I've used both Git and SVN (and Hg and CVS and TFS) and in all cases you can use whatever tool you want for the actual merge of code. I'm not anti Git, there are complex reasons for choosing VCS or DVCS, and within DVCS there are competing products that all have their own merits and problems. It's just not 'one size fits all'. In any case, my original point was that I'm voting down this question because it's argumentative, judgmental and small minded, and the assumptions are wrong. – Keith Sep 04 '12 at 07:09
  • 1
    @Keith right, but SVN is still worse than Git. – Robin Winslow Sep 04 '12 at 07:17
  • 4
    @RobinWinslow - SVN is different from Git. Better suited to some circumstances and worse suited to others. Personally I prefer DVCS in general and you obviously prefer Git, but both of those are subjective opinions. They're not without value, but they don't belong on a site like this. – Keith Sep 04 '12 at 07:35
  • @Keith I know people love the "A and B are different, one is not better than the other, they're different" argument. It's true in a lot of cases. This is not one of them. (someone should really close this thread and stop this stupid back and forth) – Robin Winslow Sep 04 '12 at 07:39
  • **Comments are not for extended discussion. Please proceed to chat if you would like to continue the holy war. Thank you :)** – maple_shaft Sep 07 '12 at 01:17

6 Answers6

50

SVN is not dead at all. It's is still in extremely wide use, and it's not going anywhere anytime soon. SVN is much simpler to use than distributed version control, especially if you're not actually running a distributed project that needs distributed version control.

If you only have one central repository (which is all your company will need if they're still small enough to get by without source control so far), it's much simpler to use SVN to interact with it. For example, with SVN you can pull changes from the repository, or commit your local changes to it, with a single operation, whereas HG and Git require two or three steps to do the equivalent work.

And with the recent revisions, SVN has fixed a lot of the performance issues that made people prefer HG and Git. It's significantly faster now than it was a couple years ago, and at this point, there's really no good reason to look at HG or Git for your project unless you actually need the advanced features of distributed version control.

Keith Thompson
  • 6,402
  • 2
  • 29
  • 35
Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 18
    I don't entirely agree with your estimation, but I'd like to add one important point in favor of SVN: Many people in the industry are comfortable with SVN but don't know enough Git to work comfortably with it. If your whole team is used to SVN, then switching to Git might come at quite a cost. (The opposite can also be true, of course). – Joachim Sauer Sep 03 '12 at 05:44
  • 8
    I would upvote this dozen of times if I could. Many people go with the fad, but don't really think why would they need distributed source control. – Euphoric Sep 03 '12 at 05:45
  • 24
    @Euphoric: I know precisely why I always want distributed source control on every project. It has the important side-effect of making branching and merging simple, obvious and reliable. Subversion is still bogged down in corner cases with branching because the basic model it chose simply makes it more complicated. – Jan Hudec Sep 03 '12 at 07:53
  • 23
    Distributed version control is not a "fad". It is an *evolution* of source control, just like concurrent version control was an evolution over the file-locking paradigm. – JesperE Sep 03 '12 at 08:29
  • With all the recent improvements, svn is still *much* slower than git. And I cannot see how can it be "simpler" to use, with all its weird implicit assumptions, tricky merge procedures and counter-intuitive branch handling. No, the only real reason to use svn is hooks, which can be very important in an enterprise environment. – SK-logic Sep 03 '12 at 08:30
  • 1
    It is not so much "need" as convenience. My typical workflow consists of 1. create branch, 2. make changes, 3. test, 4. integrate into mainline. As soon as I'm working on my own branch anyway, I see no point in having to phone home to the server for every action, this just adds unnecessary delays. – Simon Richter Sep 03 '12 at 08:34
  • 3
    @SK-logic: Try explaining git to a non-programmer. – Michael Borgwardt Sep 03 '12 at 08:45
  • 6
    @MichaelBorgwardt, I actually did it a number of times. It is much easier than with subversion, the fact that everything is local helps a lot, there is no need to explain the "client" and "server" interaction. Workflow in git or hg is much more natural and intuitive (if you stay away from the tricky bits like history editing). – SK-logic Sep 03 '12 at 08:52
  • 2
    @SK-logic: My experience has been exactly the opposite. Even locally you have working copy, index and repository, which is one more thing than in SVN. And at that point you're not even doing any collaboration yet. – Michael Borgwardt Sep 03 '12 at 10:06
  • 3
    I don’t think this is even factually correct. Even without making use of the distributed aspect, Git and Hg simply offer a step up from SVN in usability and sheer power. There may be a slightly bigger learning curve but I’ve actually found the opposite to be true. I never understood how to perform branching properly on SVN. it simply doesn’t work. With Git/Hg, it’s trivial. – Konrad Rudolph Sep 03 '12 at 10:07
  • 1
    Central repositories are inside a company network and those networks should be only accessible with a VPN (even for small companies). Being mobile and coding somewhere else than company building is normal. Connect to VPN just to do a commit is not speeding things up, and committing to a central repo many times messes up that repository. GIT encourages you to commit as often as you can, as you'll only mess up your own repository. When you finished something usable (for others), you push that code, in that way the "central" repository will be kept clean (and small). – karatedog Sep 03 '12 at 10:45
  • 4
    @Euphoric: I didn't know why I needed DVCS too... until I used it. After you get past the learning curve the difference feels almost as great as "SVN vs. no source control" (at least to me). – Jon Sep 03 '12 at 11:14
  • 2
    Another useful feature of subversion that, AFAIK, git does not support, is the `svn:externals` functionality. This is very useful for shared source subtrees across projects. Also, subversion lets you check out subtrees of your project in isolation. – Lucas Sep 03 '12 at 13:00
  • @JoachimSauer It may be true that it's easier to employ people with SVN experience than with Git experience, but seriously Git is not *that* hard to learn. You would be doing your whole team a huge favour by allowing them to learn to use evolved version control systems, rather than letting your whole team fall behind. – Robin Winslow Sep 03 '12 at 14:02
  • @Lucas - git has something called submodules which may be a good substitute for svn:externals – Ken Liu Sep 03 '12 at 14:45
  • 1
    Hmm, this seems to boil down to: "SVN is still in use because GIT is hard to learn." A decade later, I wonder what the answer is. – Django Reinhardt May 28 '21 at 16:46
  • @Euphoric Fad, eh? Mercurial was "initially released" the same year as Git according to wikipedia, and 5 years after SVN. – foxtrotuniform6969 Nov 15 '21 at 20:00
19

Client tooling hasn't been mentioned yet. You can certainly do everything with a command line script but having GUI integration can be a real productivity boost.

We work mostly with Visual Studio; integration into the IDE is definitely better with SVN than with Git right now. This may change in the future, but I'd certainly weigh this into your decision just as much as the version control functions.

Just like everything else, a version control system isn't a goal in itself, just a tool to get you where you're going. Pick the one that's going to get you there fastest based on your situation.

njr101
  • 291
  • 1
  • 3
  • This is good point. I think one of the reasons why people preffer Git over SVN is that Git has better CLI tooling. But this can be offset with good 3rd party SVN GUI, like TortoiseSVN on Windows. – Euphoric Sep 03 '12 at 07:41
  • 2
    This is one of the reasons we went for Mercurial (and TortoiseHg) over Git. The advantages of distributed version control *and* decent tooling and IDE integration. – Arjailer Sep 03 '12 at 11:03
  • 1
    Considering that Microsoft now owns GitHub, I would assume that any MS product will have much better Git integrations going forward. I mostly just use VSCode these days and it comes with Git support baked in by default and works very well. I have no idea if it come with any SVN support on the other hand. – Ghos3t Apr 15 '21 at 16:35
17

I'm a Git fan. Recently I had to admit that one of the downsides of Git is that it identifies versions with hashes as opposite to svn's release numbers. The release number can be easier passed on by phone or something like that.

And that's the only pro I can imagine. If you really want to rely on that feature you can have it in a distributed and/or centralized VCS Bazaar. In Git there are tags that can serve the purpose.

Anyway I just couldn't imagine developing without quick branch switching, and stashing. These two features alone beat SVN, where as far I remember the same task required creating and checking out a whole tree into separate directories to achieve the same goal.

Those so called "advanced features of distributed version control" come with the time, and you don't have to learn them at the very beginning. Don't be scared of them. They are here to help you, not to get in the way. And there's no problem to set up a central repository for a DVCS.

Rajish
  • 309
  • 1
  • 4
  • 1
    This is actually moot, git only needs a large enough part of the hash to be able to disambiguate, usually something ~ 6 chars is enough, not the whole hash. – TC1 Sep 03 '12 at 08:30
  • 2
    In practise, you never pass the git hash around. You can use any unique prefix of the hash, which typically is 6-7 characters. – JesperE Sep 03 '12 at 08:32
  • 3
    @JesperE: Yes, but SVN release numbers increase sequentially over time, while Git's hashes, even if you abbreviate them, might as well be random. – Keith Thompson Sep 04 '12 at 02:53
2

"If you have a task that can be done on six hours, it is better to write a tool that does it in 20 minutes, even when creating the tool takes six hours?"

Distributed Version control is a different beast to tackle. It requires substantial learning for each developer. If you have the buffer to accommodate the learning process for each developer, you should move to a good distributed version control system. Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.

Distributed Version Control seems to be an eventuality. It is here to stay for a very long time, it is better that we adapt to it sooner than later. I remember the same discussion when SVN was new and people were used to CVS, lots of arguments were given for not using SVN, but eventually SVN became the most popular version control system.

If the company is well established with a lot of source code in the existing version control system, moving to a new system is a big task, but if the company is small or starting up, moving to a new version control is very easy. But if you stick to an older version control (in a new setup) you will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration anyway.

I have seen a lot of pro SVN comments, but all of them tend to be of the nature "SVN is not bad" rather than "SVN is better". So I would strongly recommend that you choose a Distributed Version Control (such as Git) for your project.

EDIT Advantages of GIT over SVN

  1. No dedicated server required Actually, both can be used w/o a server.
  2. Can continue development even without a network connection.
  3. Branch management is much easier.
  4. Better support from CI tools such as Bamboo

Someone mentioned tooling (for visual studio) as a reason to stick to SVN. http://gitscc.codeplex.com/ provides GIT support for Visual Studio.

sleske
  • 10,095
  • 3
  • 29
  • 44
Apeirogon Prime
  • 389
  • 1
  • 16
  • 6
    SVN *does* handle **binary files** better then Git or Hg. – Fake Name Sep 03 '12 at 07:42
  • Basically, if you have a lot of binary files (like PCB layouts, etc...) the local Git/Hg history will store **a copy of every change you ever made locally**. This isn't a big deal for text, since git/hg/bzr, etc.. store the files using deltas. However, this does not work with binary files. Basically, if you're working with binary files (e.g. outputs from most PCB/3D modelling software), SVN is a better option. – Fake Name Sep 03 '12 at 07:47
  • 4
    "You will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration..." Sorry, I can't agree this is a good reason to make the move today. I've worked on many projects where this approach leads to making things more complicated than they need to be and the project is cancelled long before it ever gets to take advantage of those future benefits. Sometimes good enough, is good enough. Stick to YAGNI and take what does the job today. There'll be time enough for worrying about migrations later. At least you'll still have a project. – njr101 Sep 03 '12 at 07:48
  • 3
    `Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.` I completely disagree with this. It may have some perceived benefits in some circumstances, but something as simple as the version number in svn being human-readable is a massive benefit in many organisations. – TZHX Sep 03 '12 at 07:57
  • Thanks for the comments @FakeName, I was unaware of the binary handicap of git, possibly because we do not use large binary files in our projects. Anyways, storage space is the least of my worries. – Apeirogon Prime Sep 03 '12 at 08:00
  • @njr101 I agree with YAGNI here, and for saving the project, I would go with GIT and not SVN. To start a project with SVN i have to think about a Server setup. But to start a project with GIT i have to just initialize my local directory without worrying about explicit Server Setup. So YAGNI will compel me to use GIT – Apeirogon Prime Sep 03 '12 at 08:04
  • 1
    @apeirogon - It all comes down to what you're going to put in the repository. The HEAD alone of one of the main repositories I work with is 11.1 GB! If I had it in a Git/bzr/hg repo, it would probably take up 100+ GB. – Fake Name Sep 03 '12 at 08:13
  • 1
    Of course, this is because this particular repo is full of PCB files and 3D models, which are all binary in format, and not very space efficient. The recommendation here (Electronics.SE, e.g. for people storing PCB ddesign files, etc) is very different then if it's for someone storing source-code. – Fake Name Sep 03 '12 at 08:15
  • 1
    @FakeName This only partially true. Git uses efficient delta compression, so if you do only small changes to a binary file, git will store these changes very efficiently. The problem is that if you store binary files that are already compressed (like an Open Office document) then a small change in the original data usually changes the whole compressed file. So the changed file seems to be completely different and GIT's delta compression cannot help much. – Petr Sep 03 '12 at 08:17
  • 1
    This should not be a discussion of which is the "better" system. It is merely about pointing out the pros and cons of both. The OP can then make an informed decision based on the requirements in his company. Git certainly has many advantages, but it also has a steeper learning curve for developers coming from a non-DVCS. (Sidenote: "Maybe better googling skills are required". I do not feel the sarcastic tone is particularly constructive. As my answer states, VS Git integration certainly exists but it is simply not as mature as the SVN equivalent today) – njr101 Sep 03 '12 at 08:19
  • 1
    *the version number in svn being human-readable is a massive benefit in many organisations.* Git version numbers are also human-readable; you don't need to use the full hash. Any unique prefix will do, which in practise means 6-7 characters. – JesperE Sep 03 '12 at 08:34
  • @njr101 thanks for reminding about the sarcastic tone, I removed the comment. That comment was not adding anything useful to the answer. – Apeirogon Prime Sep 03 '12 at 08:39
  • 1
    @JesperE: SVN version numbers increase monotonically over time, and have small values when there have been a small number of checkins. Git version numbers might as well be random. – Keith Thompson Sep 04 '12 at 02:55
  • Having monotonically increasing version numbers may be useful if you never branch. But in general, revisions A and A+1 may or may not be related to each other. Git versions number are random, yes, but in my experience that is never a problem. If you ever need to (which is not very often) type the version number, you only need to type a unique prefix to the hash. Git has lots and lots of ways of addressing commits which does not require you to ever know the hash. – JesperE Sep 04 '12 at 11:00
2

With SVN you can easily checkout parts of a repository down to the folder level, whereas with git, you get the whole repository, including all the history.

Depending on the situation this may have some advantages for SVN

(this also has some big drawbacks such as the hidden ".svn" garbage all the way up your folder tree).

Richard Nichols
  • 189
  • 1
  • 2
  • 5
    note: no .svn garbage since v1.7 - its now all stored in a single location. – gbjbaanb Apr 10 '13 at 09:35
  • This is not correct - git allows you to checkout out the files only, without the history, and it is also possible to checkout out only parts of the repo - single files if you want. It's a little more complex than svn, but the capacity is there. – Benubird Jun 20 '16 at 10:01
1

would there be any specific reason to use Subversion those days

Apart from tooling support in IDEs (which I don’t use) – not really, no. Of course SVN may be more familiar but that’s about the only reason, and I’ve found both Hg and Git very easy (and very fast) to learn.

Yes, there are all those complex guides out there which describe how Git is trivial once you understand that branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.1

I don’t understand that. But you know what? It doesn’t matter. You don’t need to know any of that stuff to use Git.

For the most part, Git and Hg are easy to use and they have definitive advantages over SVN. The elephant in the room is of course branching: branches just work in Git and Hg. By contrast, in SVN they are painful at best and broken at worst (merging multiple heads).

Of course you can still use SVN. You can also still use Windows XP. However, the majority of users who have tried both agree that one of the alternatives is vastly superior.

1 Yes I get that this is a joke. I think.

Konrad Rudolph
  • 13,059
  • 4
  • 55
  • 75
  • A Git tutorial with homeomorphic endofunctors mapping submanifolds of a Hilbert space? I need to read that! But doesn't this rather apply to Darcs, which is written in Haskell (which I reckon _endofunctor_ refers to) and inspired by quantum mechanics (hence _Hilbert space_)? I really can't see what Git and HG have to do with these things. – leftaroundabout Sep 03 '12 at 18:58
  • @leftaroundabout It’s a joke. The description isn’t even accurate (as far as I know). It’s a riff on the many tutorials which start with “git branches are easy once you realise that …” and then there’s a complex domain-specific metaphor after it. – Konrad Rudolph Sep 03 '12 at 21:50
  • 2
    Have you ever considered that all those overly-complicated tutorials exist for a reason? And what's it for anyway? I've never understood the obsession the DVCS crowd has with branching and then re-integrating a branch for every little thing. That's always felt to me like a solution in search of a problem. Re-integrating a branch in SVN is difficult because *that's a really dumb and conceptually wrong thing to do in the first place*, and I really don't find any argument that boils down to "our product makes doing the wrong thing soooo much easier" very persuasive. – Mason Wheeler Sep 04 '12 at 03:08
  • @Mason Well there are conceivably complex features in Git but you normally don’t need them – I never have. As for branching being a conceptually wrong – just … no. There’s presumably no argument that can convince you, you simply need to try the workflow yourself to see how useful it is (but have you never worked on several features/bug fixes in parallel?). But if you’re not using branching you’re essentially limiting yourself to a tiny part of why source control is useful. – Konrad Rudolph Sep 04 '12 at 07:04
  • I'm using branching. It's actually very useful. What I don't do is try to re-integrate something after it's branched off. That doesn't even work on a conceptual level. The term "branch" calls to mind a tree. Have you ever seen a tree where a branch splits off and then fuses together further down the line? I certainly haven't! Branches are supposed to diverge. You use them for different logical branches in development, for example a branch for Version 1 and another for Version 2, etc. Not "a branch for bug 81362 and a branch for bug 81363 and merge them back when they're fixed." That's madness! – Mason Wheeler Sep 04 '12 at 12:57
  • 2
    As for working on multiple changes in parallel, I'll admit that's a bit painful, but the right solution there is *shelving,* which is planned for the next SVN release. And most of the time, if you're working on multiple changes at the same time, (and especially if you're doing it consistently!) that's evidence of a wider problem which should be addressed at the organization level, not enabled with new tools. (See above, re "our product makes doing the wrong thing soooo much easier," and Joel's classic article on human task switching.) – Mason Wheeler Sep 04 '12 at 13:01
  • @Mason You are confusing a concept with its metaphor. Merging branches makes *a lot* of sense. Otherwise you cannot ever integrate two features developed in parallel – but that’s the whole point of a feature branch. No, this is not (at all) a wider problem, it’s completely normal, acceptable and even good practice in some cases. *Do* develop multiple ideas in parallel. And branching enables this. Painlessly. – Konrad Rudolph Sep 04 '12 at 13:47
  • @Mason And, just to make this clear: having independent branches for independent bugs / features is *not* “madness” (it just seems like that to you because in SVN it doesn’t work. If all you have is a hammer nothing looks like a screw). And that’s what you *do* use branches for. Not in SVN obviously, since it simply doesn’t work there. But that’s a limitation of SVN, not a fundamental objection. In Git/Hg, this is definitely good practice. It works, it’s encouraged and it makes everything easier. – Konrad Rudolph Sep 04 '12 at 13:49
  • 3
    @KonradRudolph Merging branches back into the trunk works just fine in the latest versions of SVN. It's been getting steadily better for several years to where it's very good now. – Adam Bruss Sep 21 '12 at 16:11
  • I always feel like facepalm if I hear words like "painlessly". In my world merging/branching always have the potential of creating pain and the measures you can take to reduce the pain are more on a project planing level than which VCS you use. – grenix Jun 09 '21 at 14:54
  • @grenix I have to strongly disagree here. Compared to SVN, merging branches in Git really *is* painless. The difference is vast. Yes, project planning plays a role too, and if you’re using branches incorrectly (meaning, have long-lived branches that are not kept in sync with changes to upstream branches), merging will still be painful. But the whole point of branches in Git (compared to SVN) is that they facilitate an organisation which *does* make using them painless. And contrary to what others (e.g. Adam, above) claim, this is still not the case in SVN. – Konrad Rudolph Jun 09 '21 at 15:26