Version Control: Compare Hosting

Version Control and Hosting

Version Control, also called Revision Control or Source Control, is a system for tracking changes to documents, code, or other files. 

Version control systems can be standalone applications, built into document editing applications (like Word or Google Docs), or embedded into content management systems (like WordPress or MediaWiki). 

Version control systems allow developers, editors, and other team members to view previous versions of files, or restore earlier versions. Many version control systems allow for several parallel copies of the entire code base to exist simultaneously.

Coders like to code. It can be easy to get into the habit of simply opening up an editor and banging out as much code as possible. Especially if you’re the only one, if it’s a personal project or you’re the sole developer. It can be even more tempting if you’re pretty fast and you have a boss who always wants some quick little fix or tiny new feature delivered right away.

But if you are slinging new code into production without a proper version control system, you’re not really doing software development, you’re doing Cowboy Coding.

Reasons to Use Version Control

Freedom to Make Mistakes

Do you ever use the UNDO button (CTRL-Z) while working? Of course you do. It’s one of the most important features of modern computers.

What the UNDO button gives you is the freedom to make mistakes. This is one of the advantages you get from Version Control. Perhaps the most important advantage.

With Version Control, you can try something out — a new solution, a new feature, a bug fix — and if it doesn’t work, you can simply revert to an earlier point. (Like save points in a video game.)

This is helpful for two reasons:

• You will make mistakes anyway, so you might as well have a way to correct them.
• Once you know you have a way to reverse mistakes, it becomes much easier to venture into unknown territory and take risks with novel solutions or untested ideas.

Version History

Have you ever worked on a project over a long period of time and someone who uses it says, “Didn’t the Exit button use to trigger a save warning?”

(Author’s note: I have had this exact situation more than once.)

If a system exists for a long enough period of time, it is inevitable that some features will be changed and removed. Usually, even with removed features, there was some reason for having the feature in the first place. But there was also a reason for removing it (unless it was an accident).

Later on, when someone shows up and asks about some feature that used to be there, you can either try real hard to remember or (if you have version control), you can go look it up and come back with a definitive answers about what that feature used to do, when it was removed and why.

This is particularly helpful if you either have to re-implement the feature, or defend its continued exclusion.

Paper Trail

Closely related to Version History, but about developers, not features. This is not a literal paper trail (usually), but Version Control allows you to see what changes were made, when changes were made, and who made the changes.

This is helpful when trying to piece together why things are the way they are, whether you are trying to assign credit or blame, or just trying to figure out who to ask about some specific feature or implementation.

Backup

Usually, version controlled repositories are stored in multiple locations. This saves your project from having a single machine as a catastrophic single point of failure.

Easier Collaboration

If only one person is working on a project, you might be able to get away without using any version control system (though it’s still probably a bad idea). However, if multiple people are working on a project together, the risk of people over writing each other’s changes or creating incompatible code is too high to not use some kind of serious version control system.

Deployment

How do you move files from your local machine to your test and production environments. Some people just keep an FTP window open and drop files in as they change them. This is unwise. It’s too easy to leave a file out. And if there is an unexpected problem on the server, it becomes difficult to reverse your changes.

If you are using certain types of Version Control (especially git), you can simply push changes all at once to a remote server (the dev, test, or production environment), and easily roll back any changes that cause an unexpected problem.

Types of Version Control

There are basically two types of Version Control Systems:

• Centralized — In which a single, master code based sits on a server and files are checked-out (locked) by developers. Changes are pushed back to this central code base and then the central code base is used for deployments into production.
• Decentralized, or distributed — In which every person has a complete copy of the entire code and history, and no node is especially privileged. Usually this is combined in practice with the Centralized paradigm, and one single public repository (the one on GitHub, usually) designated as the “origin.”

Pros and cons of a distributed (decentrailized) version control

The most obvious difference is in terms of access and convenience. Think of a centralized system as accessing a shared Dropbox folder through their web browser; where as a distributed system is the equivalent of syncing that shared folder to your own computer. 

With a centralized system you need to first access the system, then download the files you are working from to your computer, and in some cases check them out before you can begin editing.

With a distributed system, the files are already right where you need them. All you have to do is open them up and get to work. This is a huge advantage in terms of speed and efficiency. The only time you need to communicate with the server is to pull a file from it or push a file back to it. This also allows users to make several changes locally, prior to pushing them out to everyone else working on the project, or they can send changes to select team members for review, before making them visible to the entire team. 

On the other hand, since the entire project and version repositories are stored locally, it can take up a considerable amount of space on your computer, particularly for large projects, projects that include large files such as video or images, or projects with an extensive revision history.

Version Control Systems

• CVS — Concurrent Version System
• git — Popular distributed version control. Forms the backbone of GitHub (though can be used without it).
• SVN — Subversion, by Apache. Centralized version control.

CVS vs Git

CVS has been a go-to for version control since the ‘80s, and therefore has a large following, but lacks many features found in newer version control systems. The most obvious difference is that CVS is a centralized version system, meaning everything is stored on a central server; whereas, Git uses the distributed method, so that every user has a complete copy of code. This gives Git a major advantage in terms of speed and accessibility (if the main server is down, or you’re offline, you can still access the files you need).

Another major difference is how the two system track changes. With CVS, changes are tracked per file. Git tracks changes at the project level. This means, if you’re working on a large project with several files in play, Git allows you to track all the changes that occur across all of the files between each new version. 

That’s a major advantage is you’re trying to track a bug in a single version, or even just compiling a set of release notes. On the other hand, by tracking at the file level, CVS makes it easier to narrow in on a single element of the code to do a partial check; this is much more difficult with Git.

Several smaller differences exist as well. You cannot rename files in CVS, as it will break the version tracking. Git features rename detection, which allows it to maintain that history. CVS has limited support for binary files. Git does not support as many keywords as CVS. Git offers considerably more tool for developers to take advantage of, and also provides much more freedom in terms of access and permissions, because it is not restricted by having to rely on a centralized repository.

Subversion (SVN) vs CVS?

Subversion was developed to improve upon the CVS experience, while still maintaining a high level of compatibility with the older system. Both systems are free and open source, and both use a centralized system for storing project repositories. 

With CVS, copying, deleting, or renaming files will result in a corruption of the version tracking; whereas, Suversion has added support for these operations. Subversion also supports binary files, which were limited with CVS. Subversion also redesigned the way branching is handled, allowing it better track who made changes, when, and why. And you can easily see which branches are currently active.

In terms of network connectivity, Subversion adds the ability to use HTTP-based WebDAV/DeltaV protocol and the Apache web server, which improves the communication between the server and clients, and allows Subversion it to take advantage of additional features, such as authentication and wire compression.

Choosing between Subversion and CVS will largely depend on the system you inherit. Since CVS has been around for nearly three decades, it is used and trusted by a large number of institutions. It is a mature, stable product, which provides a great deal of familiarity, but also means you won’t have access to many newer features.

If your company is already using CVS, chances are you will wind up sticking with it. However, if you are looking to update your version system, migrating from CVS to Subversion won’t be nearly as difficult as trying to move to a distributed system such as Git or Mercurial.

Git vs Subversion

Many of the same comparisons made above for Git and CVS also apply when comparing Git to Subversion. Git uses a distributed system for storing project version, while Subversion uses a centralized system. Subversion tracks changes by file, while Git tracks them by project.

On the other hand, unlike CVS, Subversion supports file name changes, as does Git. And while the distributed model allows for easier access and permissions, Subversion incorporates significantly more network connectivity features than CVS.

In recent years, Git has been quickly catching up to Subversion in terms of usage, largely due to the convenience and flexibility the distributed model provides, particularly as more and more organizations spread themselves out geographically. However, many organizations are still tied to older revision systems, often CVS

. If you’re organization is looking to update from an existing CVS system, Subversion is the obvious choice. While it’s possible to move to Git, it will be much more difficult.