Introduction to Version Control Models
In Source control Models we have two main Models – Centralized and Distributed – version controls, both have different advantages and disadvantages, lets quickly get through both models to get to know each one in a deeper details.
Centralized Version Control Model
Centralized VC is based on the idea that we have only one repository (Copy of your Project) centralized in one computer which take the role of a server with multiple clients which connect to it to download a working copy of files making changes to it and then upload it back to the server after resolving conflicts if it occurred.
one of the things that characterize CVCM is the fact that the server will always have an idea if someone is working on a specific file or not, as you have to let the server know you are going to work on a file (Checking-Out) and also let the server know you are going to commit changes back to the server(Checking-In), this results for following advantages
- The ability to monitor each and every file in your project at any time, get information like who is working on it, who is the last person who changed it.
- Since clients has to request working on a file, you can set several permissions levels on each and every file.
- Since we only have one Repository, it means CVCM works best for large scaled projects with millions of files
However think about enterprise projects with multiple geographical teams working on different modules of the projects, this would mean every developer will have to have connection to the server every time he needs to check-out, check-in a file, which result on heavy load over network not to mention relying on the internet.
What about if you have made a work around over a bug or feature and want to save a copy of it locally ?!
Distributed Version Control Model
In distributed version control model whenever a developer clone server repository it means he gets a whole local copy of the repository to his machine, where he can now checkout files from local repository edit it and then commit it to his local repository and then push or pull to the remote server later when needed.
but what this gives us ?
- Best offline experience ever!, you can even branch, merge locally without having to communicate to the server.
- No rely on connections or internet, which allows developer to be more productive when not connected to a network
- If the server failed any other local repository is a complete back up to the server with history of changes, logs etc.,
- Initial cloning of the server repository can be slow as the client has to copy the whole repository with history, logs and everything to his local computer.
- Unlike CVCM, monitoring which files are being edited or who is working on which files can be hard.
CVCM vs. DVCM
Remember the flame war we used to have every time we discuss which gearbox is better than the other?
Manual(Standard) or Automatic Gearbox, its exactly the same when talking about Centralized verses Distributed, both has its advantages and disadvantages.
Team Foundation Server 2012 or Less
In previous version of Team Foundation Server we had CVCM, that what we loved and used, it allowed one Centralized repository, and worked great for large scale projects,
In Team Foundation Server 2012 Microsoft introduced Local Work-Space as an attempt to overcome CVCM disadvantage of not allowing working offline easily, by providing a way to work offline and enabling developer to edit, delete or rename files and delay informing the server of these changes until they get online, where server would discover pending changes and allow developer to resolve conflicts and then safely commit his change-sets,
Local Work-Space allowed CVCM to have Edit-Commit model which allows developers to work offline, however CVCM couldn’t beat DVCM on providing the best offline experience. and on the other hand DVCM cant beat CVCM for providing best experience working with large scale projects.
So developer has to only pick one option and fight for it CVCM or DVCM just as drivers had to choose one options Standard or Automatic Gearbox,
Lucky drivers cars manufactures came up with a new gearbox which combine the advantages of the Standard and Automatic Gearbox ! and its called Steptronic !
And this is exactly what happened with Team Foundation Server 2013 !
Team Foundation Server 2013 and Git Support!
Microsoft wanted to combine the advantages of CVCM and DVCM, and give the developer the option to not only choose which Version control model he want to work with but can also combine both (Using Git-TF) !
In Visual Studio 2013 Microsoft introduce full support for Git Repository.
Picking up between TFVC and Git
Creating New Team project
Team foundation server 2013 can host fully fledged Git Repository, which you can use any native Git Client to connect to it and work with it just as you do with regular Git Server like Git-Hub
As you can see you can still use the same process template to Git Team project not to mention the same tools you used and love inside Team foundation Server 2013 and Visual Studio 2013!
Visual Studio 2013 IDE and Git Support!
Visual Studio 2013 IDE can now be used to connect to any Git Server and act as native Git Client!
Using TFS2013 you can even have one enterprise Project with two teams working on different Version Control model!
So let’s look at a high level overview over the underlying architecture of VS2013/TFS2013 to see what we can offer at the moment to our Enterprise customers and community
Project 1 use Team Foundation Server VC (Centralized Source Control Model) while Project 2 uses Git (Distributed Version Control) both has no awareness if the other team is using different model, as Git-TF can be used to Sync between both repositories!
every and each developer is free to use the IDE he likes! and the platform he likes !, think of how this will help with projects with different teams background and different platform!
It Doesn’t matter if you are a java developer on Windows or on Mac or an IoS developer you can use the IDE you like and used to and be part of an enterprise geographical project using Team Foundation Server 2013!