One word to summarize Git and other DVCS

Question

As I getting acquainted with Git, I feel more and more that:

Git and other DVCS jump a step futher than traditional centralized VCS in that they not only check out files in question, but also the whole version database.

I think this is the major difference between DVCS and CVCS, and also the major foothold of all other benefits of DVCS.

Or, let's put it this way:

Multiple Local VCS + A Centralized Backup = DVCS.

Changed the above equation to this:

Multiple Local Clones + A Centralized Backup = DVCS.

Right?

Not sure your summary is accurate. I have edited my answer. – VonC Aug 25 '11 at 08:41 — VonC, Aug 25 '11 at 08:41

score 4 · Accepted Answer · edited May 23 '17 at 12:12

4

What you are describing is the very nature of a distributed system: the whole repository is cloned (with its full history).

a DVCS mixes version control (branching and labels) with publication (push/pull to/from remote repo)

But there are other characteristics that differentiate a DVCS from CVCS.
Especially in terms of workflow. See "Describe your workflow of using version control (VCS or DVCS)"

And don't forget that a DVCS doesn't have authorization or authentication. However, there are solutions to provide those, e.g. apache2-authn-redmine in combination with the Redmine Project Management System

The OP smwikipedia adds:

Multiple Local VCS + A Centralized Backup = DVCS.

I don't think you can summarize that way, especially considering it would be difficult to emulate the push/pull features since most of the VCS (SVN, ClearCase, Perforce, ...) have no "local" repo, only local working spaces, and depend heavily on their central repo.

edited May 23 '17 at 12:12

Community

1
1

answered Aug 25 '11 at 08:29

VonC

1,262,500
529
4,410
5,250

The last part on authorization is not correct - DVCS even allows for greater possibilities. If you want to the classical CVCS-style for branches with authentication, check out [Redmine](http://redmine.org), which provides an apache2-auth-module. – Lars Aug 25 '11 at 08:40
@Lars: I am not sure what you mean by Redmine (and by mentionning 'auth', which is for *authentication*, not authorization). If you consider a DVCS *alone*, the principle is: "if you can access it, you can clone/pull/push". No authorization there. But if you couple a DVCS with another system (SSH, Apache for authentication) (Gitolite for authorization), then you can get those features. – VonC Aug 25 '11 at 08:44
That's the point: What I tried to say is, you have freedom to choose your workflow (more than with CVCS). The most used (open) DVCS workflow is with pull-requests. I clone your repository (no authorization or authentication there), make my changes and send you a pull-request, so it's your responsibility to auth* me. In a corporate environment, I use authentication and authorization to keep the repository private. I may even use an automatic gatekeeper to only accept pull-requests (or pushes), if they pass a test-suite (to fight breaking builds in continuous integration development), ... – Lars Aug 26 '11 at 15:19
@Lars: yes, but the main point to keep in mind is that DVCS alone won't give you authentication and authorization. While a CVCS has, from its core architecture (client-server) the opportunity to provide both at the server side. And that has nothing to do with the workflow, and how you want to use it (like, for example, http://stackoverflow.com/questions/3209208/what-is-the-cleverest-use-of-source-repository-that-you-have-ever-seen/3209767#3209767) – VonC Aug 26 '11 at 15:36
I think we are talking about the same, but with different words. I edited your answer to reflect that. Is it okay that way? – Lars Aug 26 '11 at 15:48
@Lars: sure, thank you for the edit. I approved it, but it will need one more approver to go live. – VonC Aug 26 '11 at 15:51

score 0 · Answer 2 · answered Aug 25 '11 at 08:28

If you really want to put it in one phrase, the main difference CVCS and DVCS for me is the fact, that everyone is working on their own versions, interchanging their updates (thus the distributed in DVCS). If you don't specifically tell git to, it won't download all branches from other contributors.

Check out gitworkflows for the idea behind it or the Bazaar Workflows for a very nice graphic repesentation of the possibilities (it is also possible to use git or any other DVCS like a CVCS).

score 0 · Answer 3 · answered Aug 25 '11 at 08:29

That's one difference, yes. It allows to work off-line and propagate changes later.

Another difference, which can be seen as a consequence, is the branch management. When you work (and commit) locally, you create a new branch, by design. Changes propagation is simply branch merging. That's why git (and certainly hg and bzr) have strong merging algorithms.

(My first answer was simply, "yes." For once I'm glad of the 30-char limit.)

score 0 · Answer 4 · answered Aug 25 '11 at 15:56

Except the centralized backup is completely optional. The "central" repo is a social distinction, not a technical one. You don't really check out "the one" version database. Rather, any given clone is the version database.

My one-line description is:

As many branches as you want, in as many repos as you want, sharing what, how, and with whom you want.

One word to summarize Git and other DVCS

4 Answers4

Linked