mercurial for OS projects and svn for Enterprise p

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

No, definitely not. This suggestion that DVCSes would not be suitable for the enterprise is pertinently false, a common FUD argument from people who for whatever reason have a desire not to abandon SVN.

In actuality, also in enterprise settings DVCSes give you many benefits:

• Ability to check in frequently without risking blocking other people
• Offline working
• High performance
• Effective branching/merging
• Pull access pattern

With regard to that last one, you can give seasoned developers direct push access to the main repository, while for new or junior members their mentor pulls from them and review their changes before pushing them.

Tying in to the discussion in the answer above; in this way DVCSes give you more control over your repository, while with SVN generally the only real workable model is to give all contributors commit access to at least parts of the code.

You may have less fine-grained control over permissions for sections with the code, however you can give different groups (e.g. documentation team) their own clone of the main repository, and merge it back periodically after review. Or put the documentation in a whole different repository altogether.

Often you need to un-learn practices you learned with centralized VCSes, go back to the use cases and what it is that you want to do, and then consider how a DVCS could empower this.

A very good article to read to get insight in the differences between version control systems is Making Sense of Revision-Control Systems.

Answer 2

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.