But VC is not simultaneous, user specifies when to share
This makes sense for code which must be "complete" before sharing
Good for:
Text files
Code files
Small program resources (that don't change often)
e.g. program icon files
Bad for:
Binary formats
e.g. Word documents, PDF
Any small change in a binary file will usually cause the whole file to be marked as changed, which can lead to a very large and inefficient repsotory
Large data files
Specially if they change often or significantly
Concepts
Repository
The "place" where the files are stored
Often a web address from which the files can be accessed
Often abbreviated as "repo"
Client software
VC requires special software to download and upload changes
More concepts
Fork
A new independent copy of a repository
Branch
An independent specific "version" of a repo, usually to implement specific functionality (before actually have the other collaborators use it by default)
More Concepts
Merge
Bring the changes from others together with your own
Conflict
What happens when you and someone else have modified some file in the same place
Version control systems
CVS (Concurrent Version System)
SVN (SubVersioN)
Git
Many others:
Bazaar, Mercurial, etc.
Distributed VC
More common one today
Does not rely on a central server
There can be one, but it doesn't have more "power" than any of the other peers
All copies of the repository are (almost) identical.
They all have all versions
And they can have all branches (although under certain circumstances they don't...)