Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

Git/Mercurial have been becoming more and more popular. I have seen plenty of articles comparing SVN with Git/Mercurial, but I am wondering if there开发者_JS百科 is really any reason to still use SVN. It seems like there are plenty of tools for Git/Mercurial now which should help spread its corporate adoption.

Are there any reasons to still use SVN? Is Mercurial/Git finally ready for corporate adoption?

On the one hand, SVN integration (with IDE, frameworks, wikis, ...) is very mature, as well as its GUIs and code browsers (even though DVCS like Git and Mercurial progress every day).

On the other hand, introducing a DVCS in an Enterprise environment is still not a trivial task:

Some requirements are not easily met (in terms of security and access control, administration and restriction of access)
The DVCS paradigm is more complex to understand, with lots of pros and cons.
You really need to leverage its many workflows instead of relying on the SVN centralized one.
The transition from CVCS to DVCS is difficult

Just to be clear, using a DVCS can be a very valid choice:

for a new project, where the developers are not tied with legacy tools or processes
especially when the developers are not geographically located in the same place (often the case with open-source development, which is why DVCS are mainly used there).

StackOverflow (not an open source project) is using Mercurial (see HgInit, written by Joel Spolsky).
They migrated from SVN to a DVCS:

in part because their developers are now all over the world(!)
and also because the merge facilities of a DVCS are much more advanced than in SVN.
(which they need to maintain many parallel slightly different versions of their code base, between SO sites, StackExchange sites V1 and V2, Area 51, ...)
See "differences between DVCS and CVCS", or "What are the benefits of Mercurial or git over svn for branching/merging?".
For a corporate environment (where I am), any transition of any kind is not trivial, because it need to be:
- funded (money, even if the tools are free)
- supported (that means having the right people with the right competences)
- integrated (with existing legacy tools, GUIs, IDEs like a Visual Studio or many others, ...)
- administrated (in term of common servers, even for a DVCS)
- documented (especially for users coming with a CVCS like SVN background)

So DVCS can also be very useful in a corporate environment:
(See "Corporate adoption rate of Git?" or "Git-Based Source Control in the Enterprise: Suggested Tools and Practices?".)
It is (even for new projects) simply not as easily put in place than in a smaller structure or in open-source environments.

Is it considered better for a single developer?

If anything, Subversion is worse for a single developer (more troublesome to setup).

But a good reason to keep using SVN is inertia. If SVN works fine for your project (or in your company), there is no need to go through the pains of switching over. There might be some training costs involved in teaching everyone the new tools (and new workflows), with no real benefits.

I think Subversion still works better than Mercurial and Git for large files like media assets, Photoshop files, After Effects composites, etc. I remember Linus Torvalds mentioning big files as one of the very few potential problems with Git in this Google Tech Talk. Mercurial has a few extensions for storing large files outside a repository. So it seems they both suffer some performance degradation and/or other issues in that scenario.

Subversion, on the other hand, is being used by the current Blender Open Movie Project. I don't think they use it to store the rendered frames, since that would be at least a few gigabytes of data for each render pass. But still, with all the 3d scenes, objects, rigs, textures, and scripts, that's still one big repository with many large files.

I can see reasons where you might continue to use SVN if you had been using it for a long time. Especially in a small company or coding circle, the transition from SVN to either git or Mercurial, when you might not be using any of the more powerful features of them, might make you adverse to making the switch. As pointed out by Thilo, a large company using SVN is going to find that change monumental.

Also, I think SVN still has is places, particularly when it comes to teaching revision control. But that's taking from my own personal experience of learning SVN in university versus teaching myself git, so my opinions won't be objective on that.

That being said, if you were starting a repository from scratch, I can't think of any conditions where you might decide SVN is absolutely necessary. Perhaps when dealing with legacy systems.

or legacy users ;)

I don't know of any intrinsic reasons to prefer centralized vcs, there are plenty of extrinsic factors like legacy systems, managerial inertia, learning curve, etc.

DVCS is pretty much demonstrating itself to be the "better mousetrap".

The real question isn't SVN vs. Git/Mercurial, it's distributed vs. centralized. Centralized can be better in some situations such as a corporate environment where you need tight control and thorough logging.

We use subversion as storage for data, which is non trivial to merge (we do hardware development, and the design files are a undocumented binary format). SVN has the advantage that you can set locks on files, so only one developer can work on a file, and is also forced to check out the newest file before editing.

Subversion is ideal when the centralized paradigm is ideal.

One such situation is when working on papers. It makes much more sense just to keep one master copy that everyone pulls from. We don't want to create branches or tags. We just want to keep track of who makes a change and then propagate to all authors.

Subversion integrates very well with Apache!

You can use both Git and Hg as SVN clients. That means you can have the best of both worlds.

You cannot however use SVN as a client for either Git or Hg.

In many ways the ideal case is a central SVN repository with users using whichever DVCS they like as a client.

SVN is much easier to learn and use for many people, and its tooling is far more mature.

My answer is based on a few assumptions:

The subject matter you're storing in source control is source code, and what you're doing with the code is professional software development.
You should always use the best tool for the job; As the Joel Test says, you should use the best tools that money can buy - even if they're free.
External factors are irrelevant to choosing what is the best tool for the job - these are the roadblocks you must overcome to adoption. Those reasons in the meantime are excuses to continue to use Subversion, not reasons why you should explicitly use it.

Secondly, that a DVCS is considered a better, more powerful tool than Subversion. It has been discussed a lot on Stack Overflow in the past, and other answers have chimed in that most people agree that DVCS is "the better mousetrap." I don't feel it's necessary to prove this point; you can peruse the linked/similar questions already posted here. Of course, not every single DVCS will be better than Subversion in every aspect, but I believe that leading DVCS's like Mercurial, git, etc are better than Subversion is nearly every aspect.

So by my logic, if you are going to choose the best tool for the job, and Subversion is an inferior tool, Subversion should no longer be used. That doesn't mean we'll see instant, worldwide adoption, but it is my contention that--if you believe in using the best tool for the job--all organizations should plan to move to a DVCS. Of course, many will not, and I expect people will continue to use Subversion for a long time.