How to setup distributed version control in a company?

It's a good idea to have some sort of central repository, because it'll allow for you to share code, but also have a branch somewhere that you can directly generate your builds/export your snapshots from. That server will probably have more than one branch, one of which is thought of as a 'trunk' branch. Any previous releases will have their own branch, and depending on the hierarchy of your team (ie if you are divided into groups with each group working on one aspect of the application) then there may be team or feature based branches, though if you don't work that way that's not necessary Of course, because it is distributed each developer will also have their own local repository, to make things nice and fast.

Or they can each have multiple repositories, even. For instance a developer who likes to work while commuting may have a repository on his workstation, and another one on his laptop, with branches on his laptop that are 'checked out' from the ones on his workstation. It's up to him.

I guess that the 'distributed' part makes this kind of thing a lot easier, because you can commit and even branch while you are away from the network If you're transitioning from a non-distributed VCS, then you can just slip straight into the same model as before, because a DVCS is flexible enough to work in the same way. Otherwise, you can just start with a single central repository with a few branches, and it is always trivially easy to create more repositories and branches later One last thing is that you still need backups. The fact that various developers each have copies of the same thing adds redundancy, but it is not instead of backups The DVCS I use regularly is Bazaar.

I have also tried Mercurial.

It's a good idea to have some sort of central repository, because it'll allow for you to share code, but also have a branch somewhere that you can directly generate your builds/export your snapshots from. That server will probably have more than one branch, one of which is thought of as a 'trunk' branch. Any previous releases will have their own branch, and depending on the hierarchy of your team (ie if you are divided into groups with each group working on one aspect of the application) then there may be team or feature based branches, though if you don't work that way that's not necessary.

Of course, because it is distributed each developer will also have their own local repository, to make things nice and fast. Or they can each have multiple repositories, even. For instance a developer who likes to work while commuting may have a repository on his workstation, and another one on his laptop, with branches on his laptop that are 'checked out' from the ones on his workstation.It's up to him.

I guess that the 'distributed' part makes this kind of thing a lot easier, because you can commit and even branch while you are away from the network. If you're transitioning from a non-distributed VCS, then you can just slip straight into the same model as before, because a DVCS is flexible enough to work in the same way. Otherwise, you can just start with a single central repository with a few branches, and it is always trivially easy to create more repositories and branches later.

One last thing is that you still need backups. The fact that various developers each have copies of the same thing adds redundancy, but it is not instead of backups. The DVCS I use regularly is Bazaar.

I have also tried Mercurial.

Yes, but you have many options. The best diagram I've seen that explains some of them is at whygitisbetterthanx.com/#any-workflow.

That's not exactly a feature that sets them apart from the other type of VCS which are called cetralized VCS. So if the company has experience with svn for example. With a dedicated server for the repository and backup model, you can apply pretty much the same thing for the DVCS.

Yes, I think for a company, or at least one product in the company, it is best or at least easiest to have a centralized setup model. You are trying to make a single coherent product, after all. However, DVCS instills a different working spirit and mode which you may or may not want to encourage in your team.In particular, it increases experimentation (just use a local copy, and you're not bothering anyone).

It is easier for maintenance of old versions, or if you do a lot of client-specific changes that need to be kept track of without putting them in the actual product. It is invaluable when you have a team that works offsite a lot.In my company engineers often make last minute changes on site, where for security reasons they don't have internet access. Central VCS simply do not work for this scenario.

So there is a central repository, but the fact that you can work in a decentralized manner is invaluable. DVCS is a superset of centralized VCS in terms of workflows. Of course, you can still choose to use a centralized VCS if you don't think you'll need (or want!

) the additional options.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.