Question

correct me if im wrong, but isn’t distributed SCMs for OS projects while centralized SCMs are better for corporate/private projects?

cause with eg. mercurial anyone gets an exact copy of the repository with FULL history features, while with centralized you only get the latest working copy.

im more focused on private projects so i wonder if its better with centralized SCMs or doesnt it matter?

Answer 1

You can use a DVCS (like mercurial) in large corporation.

The limits of a DVCS compared to a VCS are essentially:

• size (you cannot indefinitely stored everything in a DVCS, meaning you should rethink your development data as modules instead of a monolithic set of files which can still be found in large projects)
• right access management: it is not as fine-grained in a DVCS as it can be in VCS, essentially because many external parties can contribute to a project, with different user authentication schemes. The ownership is trickier to manage.
• workflow: a DVCS workflow is more complex even if it can emulate the one of a CVCS (one central repo acting as reference for all others)

That said, DVCS allows for a new way to publish (pull/pull) data, which can help for inter-teams “pre-deliveries” (when a team want to share development even though there are still in progress and not yet officially committed to the central repository): you become a passive produced and an active consumer.

---

Tomislav Nakic-Alfirevic asks in the comments:

Could you illustrate your second point comparing a DVC with a centralized one?

The right access management is tricker, especially if the large corporation:

• has to share some of its repository with external enterprise for shared out-sourced development
• allows some of its repositories to be cloned on personal computer (when working in mobile environment on different site, where the developer doesn’t have always access to the enterprise network)

In those cases, that means:

• the user authentication is not always easy to reconcile (a same user can have different identity depending on where he/she clones the repository). A SSH-based authentication can be setup (gitosis, gitauth).
• the metadata associated with the file are limited, through Git tags for instance
  (the group of a file for instance might not exist on a given computer where the repo is cloned)
  (metadata from other tools are not transparently supported)
  (special characters in filenames can be problematic)
• the access rights are often limited to the all repository and not natively managed per branch or per file (a server like gitolite for Git must be configured for that, as opposed to a CVS which always has a server, meaning which will be more enclined to propose a finer-grained ACL)

Git for instance is a bit too simple to answer directly large corporation concerns:

People new to git (meaning, I was suggesting enhancements like this when I started too ;)) frequently talk about adding this feature or that feature, without realising that git really is very very simple.
It has files, directories, commits, tags and that’s it.
It’s power over centralized solutions is the lack of surrogate identifiers such as a
branch path, server assigned sequence number, etc.

Yes, there could be more relationships and metadata to represent a whole lot of things.
Per-file history and merging, directory renaming, cherry picking, reverting.
But these all add complications to the basic model, which has already shown itself to be capable of dealing with these things – with caveats.
But the pay-off – simplicity – is well worth those caveats.