This article features prominent methods and categories that are purely a used to securely isolate code base of projects so that there is no loop hole of failure both at natural and un-natural events of code theft or damage or crash.
Also note that this article is a purely a brush up of the concepts and does not market or dig deeper on any product as such. Readers are advised to make a note of this as well!
Setting forward about version control as it is commonly called in the industry, the first question is “Why?” Well, your question is so straight that the answer is as well straight!
Why is version control important?
If you are reading this, it’s possible that you are updating documents that look something like this: index-v12-old2.html. Let’s get away from this and on to something that will not only allow you to control your source code and files, but become more productive as a team. If this sounds familiar:
- Communicated with your team via email about updates.
- Made updates directly on your production server.
- Accidentally overwrote some files, which can never be retrieved again.
You can now look forward to this instead:
- File names and directory structures that are consistent for all team members.
- Making changes with confidence and even reverting when needed.
- Relying on source control as the communication medium for your team.
- Easily deploying different versions of your code to staging or production servers.
- Understanding who made a change and when it happened.
So it is like you insure yourself much before getting in desperate, jeopardizing situations!
Knowing about “Why” also answer a supplement must question of category the “Why” answers holds up. It is a strange fact that it is little known that we have two categories of Version Control System, the reason being people opting for such repositories are so straight in thinking that they adapt their infrastructure to suit these products which must be other way round!
Choose repository that suits your infrastructure; don’t change your infrastructure to suit the repository!
Attempting to know more about the repositories, get to know the categories in them. They are called as,
Centralized Version Control
At the time of this writing, the most popular version control system is known as Subversion, which is considered a centralized version control system. The main concept of a centralized system is that it works in a client and server relationship. The repository is located in one place and provides access to many clients. It’s very similar to FTP in where you have an FTP client which connects to an FTP server. All changes, users, commit and information must be sent and received from this central repository.
The primary benefits of Subversion are:
- It is easy to understand.
- You have more control over users and access (since it is served from one place).
- More GUI & IDE clients (Subversion has been around longer).
- Simple to get started.
- At the same time, Subversion has some drawbacks:
- Dependent on access to the server.
- Hard to manage a server and backups
- It can be slower because every command connects to the server.
- Branching and merging tools are difficult to use.
Distributed Version Control
Distributed systems are a newer option. In distributed version control, each user has their own copy of the entire repository, not just the files but the history as well. Think of it as a network of individual repositories. In many cases, even though the model is distributed, services like Beanstalk are used for simplifying the technical challenges of sharing changes. The two most popular distributed version control systems are Git and Mercurial.
The primary benefits of Git and Mercurial are:
- More powerful and detailed change tracking, this means less conflict.
- No server necessary – all actions except sharing repositories are local (commit offline).
- Branching and merging is more reliable and therefore used more often.
- It’s fast.
- At the same time, Git and Mercurial do have some drawbacks:
- The distributed model is harder to understand.
- It’s new, so not as many GUI clients.
- The revisions are not incremental numbers, which make them harder to reference.
- It can be easier to make mistakes until you are familiar with the model.
Which one is right for you? This really depends on how you work. We usually recommend Subversion if you are just getting started, are not comfortable with the command line or do not plan to do a lot of branching and merging. Otherwise, we encourage you to try Git or Mercurial and see if you like it.
Also if you are seriously thinking of coding big, then you cannot wholly get relied on your system go for Source Code repositories that best suits your needs and also make sure that they provide best integration methodologies and also for its made easier for deployments and collaboration.