views:

276

answers:

6

I am personally a SVN lover, but am starting to fall prey to the buzz that is surrounding DVCS.

SVN is free, and time tested, is DVCS the new SVN?

I am also looking for which DVCS server will win out GIT or Mercurial?

+4  A: 

Every distributed version control system that I know of is also free. Distributed systems offer so many benefits, that I think the real question is whether traditional systems will survive. My answer to that is no.

Daniel Straight
i think cvs is pretty much dead... but svn is a tank and its been a solid choice for years.
Nix
+1 Almost makes me wonder if the title of the question was meant to be "Will NON-Distributed Version Control Systems survive?"
mmacaulay
CVS is nowhere near dead, it's probably used by millions of people on many gigantic systems.
John
I have not heard of people choosing to use cvs... its generally a past choice that people are dealing with..
Nix
Git in comparison to SVN is a million lightyears in front. Git is missing proper auth though
Ronny
i don't know of a single company in this area that uses a DVCS. most use SVN and TFS, some are still stuck with CVS or SourceSafe.
stmax
@Ronny: Git is completely orthogonal to "proper auth". That's the responsibility of the server running it, as far as Git's concerned. Gitolite, Gerrit, and many online hosting services allow branch-level access control.
Novelocrat
A: 

There are iterative improvements each generation.

In the beginning, it was Source Control. Now it's Distributed Source Control. I imagine in 20 years there will be something better.

It's a fascinating time to be a software developer. There will be no going back, only forward.

George Stocker
+2  A: 

Well you can look at the advantage and disadvantages on wiki

  • Differences

    • There may be many "central" repositories.
    • Code from disparate repositories are merged based on a web of trust, i.e., historical merit or quality of changes.
    • Lieutenants are project members who have the power to dynamically decide which branches to merge.
    • Network is not involved in most operations.
    • A separate set of "sync" operations are available for committing or receiving changes with remote repositories.

[edit]

  • Advantages

    • Allows users to work productively even when not connected to a network
    • Makes most operations much faster since no network is involved
    • Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture of meritocracy[citation needed] instead of requiring "committer" status
    • Allows private work, so you can use your revision control system even for early drafts you don't want to publish
    • Avoids relying on a single physical machine. A server disk crash is a non-event with distributed revision control
    • Still permits centralized control of the "release version" of the project

[edit]

  • Disadvantages

    • Concepts of DVCSs are more difficult for developers to grasp as they are required to know more about infrastructure.

however in the end I believe what it would come down to is what companies use what. Look at COBOL, it is still used in a lot of places even though it's even taught that much anymore. Companies that already have this implemented will most likely stay with what they have instead of changing everything to accommodate the new hype. IMO.

Justin Gregoire
You can of course use a DVCS as SVN/CVS, just always push out each checkin.
Martin Beckett
You forgot a disadvantage of DVCS: You can't do file locking with a DVCS, so they aren't very useful for Binary assets (Excel, Word, CAD, etc).
msemack
+2  A: 

Distributed Source Control is great, however it really depends on what kind of project you're working on. Most companies need a centralized repository as a point that everyone can reference. So when you are looking at tools like GIT or Mercurial..it isn't the "Distributed" that is the important sell for a big company (although there are niceties because of this, this is not the most important thing). The beauty of them is the fact that they make merging branches much easier. This causes you to be able to branch more often and effectively, and commit at more intermediate steps than you would on a "centralized" system. Yes, these are largely due to the fact that they are designed in a distributed model, but not entirely so. I personally love GIT...but I use it with a centralized "repository" for work because it's what makes sense for the business.

As far as being free, that's not really an issue. Most (if not all) Distributed source control systems are free. Only time will tell who "wins out" but if I had to place my bet, I'd say neither. There are dozens of SCM out there that all fail equally, and thousands of companies use each of them.

NebuSoft
+4  A: 

Which will win, Git or Mercurial? Both will "win".

  • They are very similar in use. People who learn Git or Mercurial can easily switch from one to the other, only having to learn how to word some commands differently. (The biggest differences lie in advanced usage).

  • They are interoperable. You can push data between Mercurial and Git repositories without losing information.

  • There's no real compelling reason to switch from Git to Mercurial or vice versa.

  • Neither is much more popular than the other. Google returns 494k results for "git dvcs", and 342k results for "mercurial dvcs". Bzr has 173k and Darcs has 51k.

Dietrich Epp
+2  A: 

I don't think we'll see medium or large companies move away from centralized systems any time soon. Large companies care about centralization and control. They have governance and compliance issues to deal with and they need centralization to manage that. So I think you'll continue to see centralized systems in the enterprise.

At the same time, DVCS will most likely dominate the open source ecosystem. We're already seeing this with the recent rise in popularity of Git and Microsoft supporting Mercurial on codeplex.

Personally I would love to see a combination. I think a centralized server for tracking "official" repositories would help in an enterprise environment, but a distributed working copy allowing cheap branching and merging for individual developers would be very useful.

I blogged about this the other day specifically in regards to Subversion. I'm not sure how likely it is that we'll see anything like this come from the SVN team, but I think it could be really powerful.

http://www.sublimesvn.com/blog/2010/03/subversion-vision-conference-distributed-subversion-unlikel/

glenc
+1 for pointing out so nicely that there's no one answer for all problems.
Frank Shearar