Sell me distributed revision control

Question

I know 1000s of similar topics floating around. I read at lest 5 threads here in SO But why am I still not convinced about DVCS?

I have only following questions (not

Answer 1

Most likely, no one will sell you anything here. If you need git's features, just git init. If it does not fits for you, just don't.

If you don't know git features yet, type git vs (note the ending space) in the Google search, and see the results from the autocomplete.

I preferred Notepad over IDE until I needed Netbeans features. Seems that this is the same case here.

As you know, there were many successful projects without VCS at all.

PS. Selling git violates its license! ;)

Answer 2

DVCS is very interesting for me as it:

• adds an all new dimension to the source control process: publication.
  You do not just have a merge workflow, you also have a publication workflow (to which repository will you push to/pull from), and that can have many implication in term of:

  • development lifecycle (with repositories made only for a certain type of commits, like the one made to be released into profuctions, for deployment purposes)
  • solo tasks (you can push and update a backup repo, even in the form of just one file)
  • inter-dependencies project (when a team of project A is waiting for team porject B to finally commit to the central repo, it may resort to ask B to "pass" an intermediate development as an attached zip file in a mail. Now, all that A has to do is add B repo as a potential remote, fetch it and have a peek)

• brings a new way of producing/consuming revisions with:

  • a passive way of producing new revisions (only the one which are actively pulling from your repo will see them in their branches)
  • an active way of consuming revisions from others (by adding their repo as remote and fetching/merging what you need from them).

That means you do not depend on other delivering their work to a central repo but that you can have a more direct relationship with different actors and their repos.

Answer 3

I'm not going to sell anything here.

• What is the advantage or value of committing locally? What? really? All modern IDEs allows you to keep track of your changes? and if required you can restore a particular change. Also, they have a feature to label your changes/versions at IDE level!?

The only real advantage is that you don't need to need connectivity to the main central repository. Someone can say that Git's benefit is the fact that a developer can commit locally, preparing a great combo of patches and then pull them to the blessed central repo, but IMO this is pretty uninteresting. A developer can use a private shelve or a branch in Subversion repository to work on his task and then merge it with a mainline (e.g. /trunk) or another branch.

For me the main downside here is the fact that I have to download and store the whole Git repository on my machine. With a large project with looong history it becomes a pain and takes too much space.

Another downside of being centralized is that Git technically can't track renames or copy operations. It just tries to guess whether a file was renamed or copied based on the file's content. This results into such funny cases: svn to git migration keeping history of copied file (Guy is asking why the history of a file has been lost after SVN>Git migration, ).

• What if I crash my hard drive? where did my local repository go? (so how is it cool compared to checking in to a central repo?)

With Git, if you crashed your local storage device (HDD, SSD, whatever) and it had changes that were not pulled or pushed to a blessed Git's repo, then you are out of luck. You've just lost your time and your code. In addition to this, a crash of a hard drive with your local Git repo may halt development process for some time: Linus Torvald's SSD breaks, halts Linux kernel development.

With centralized source control such as SVN, you could only lose your last commit because all your work was already committed to the central repository to a branch, private shelve or even trunk. Obviously, you should ensure that there is a disaster recovery and backup implemented for your central repo.

• Ok Linus Torvalds gives his life to Git and hates everything else. Is that enough to blindly sing praises? Linus lives in a different world compared to offshore developers in my mid-sized project?

For such a project as Linux Kernel that used BitKeeper in the past, Git is the best source control system! But I'd say that Git does not suit everyone.

Choose wisely!

Answer 4

Interesting question.

I'm not a seasoned DVCS user but my limited exposure has felt very positive.

I love being able to 2-step commit. It suits me.

Some advantages that spring to mind:

1. Better merge support. Branch-Merge feels more like a 1st class citizen in DVCS, whereas in my experience of centralised solutions, I've found it to be painful and tricksy. Merge tracking is now available in svn, but it's still slow and cumbersome.

2. Large teams. DVCS is not only for single-user commits. You can push & pull commits between teams before contributing back to the master repository (or not). This is invaluable for certain flavours of collaboration.

3. when working on experimental functionality, it makes sense to commit frequently, but only for the short-term. I don't want always to branch the main codebase, so it's nice to be able to play & re-record. Similarly, I can see it being useful when working with Continuous Integration. If I am working for days on refactoring efforts, I may break builds for an unacceptable timeframe, but I still want to keep track of my changes.

Note that my DVCS experience is more with Mercurial than with Git. Coming from a CVS/SVN background, I've found the learning curve much easier with Mercurial (Hg). Recently-added Google Code support for Mercurial is also a boon. ... I'll even go as far as to say, that my initial response to Git was negative, but more from a usability perspective than anything to do with DVCS

Answer 5

It might be interesting to note that Subversion will probably be getting things like offline commits in the future. Of course we can't really compare those features to what's available today, but it might be a very good way to "use DVCS in a centralized manner" as described in other answers here.

Another recent post states that Subversion is not trying to become a DVCS

These things will probably mean that the repository is still centralized, meaning you can't do disconnected branching, diffing of old versions, but you can queue up commits.

Answer 6

I have been where you are now, sceptical of the uses of distributed version control. I had read all the articles and knew the theoretical arguments, but I was not convinced.

Until, one day, I typed git init and suddenly found myself inside a git repository.

I suggest you do the same -- simply try it. Begin with a small hobby project, just to get the hang of it. Then decide if it's worth using for something larger.