How does version control differ from plain backups?
Let\'s forget about the feature decoration, and concentrate on the soul of version control. Is there a clear line
Here's a few
I think you can form arguments for either lumping backups together with VCS, or for treating them as entirely separate. But I think you can't avoid talking about individual features of a VCS, as it's the features that differntiate a VCS from a backup solution:
In my eyes, these features are defining. If you ignore them, a VCS is essentially the same as an incremental backup solution.
If you look at a distributed VCS, you might find a stronger notion of keeping track of branches than in a non-distributed VCS. That is, there may not be a single head/trunk branch, but several at any given time. That's something no backup solution I've come across considers.
Version control represents the whole history of changes; backups try to make sure you don't lose it.
They are totally unrelated things. Think of version control as a kind of "time machine", which you can use to go back and forth in time with your code.
At it's basic level there is no difference between version control and backups. A version control system is an incremental backup of every change that is made. A basic, non distributed VCS, like CVS used by one developer will simply create a backup of every change that is made to a text file.
Where version control moves beyond basic backups is in the additional tools that are provided to compare versions, merge changes made by multiple developers, tag versions for release or testing and conduct other operations that make managing these separate versions possible.
The fundamental idea of version control is to manage multiple revisions of the same unit of information. The idea of backup is to copy the latest version of information to safe place - older versions can be overwritten.