A version control system (VCS for short) is a method to store source code and other iterative design materials (webpages, etc) for both collaboration and security. what sets a version control system apart from other systems (backups) is that:
This adds up to a system that permits operations on a file-based structure
·
History (seeing who
changed what when)
Manual file copy
You could do all of this just by making appropriate copies of files.
·
Easy to do - no special
software required.
o But you can compress things.
o Barney and Betty both start editing foo.c,
perhaps by making copies.
o Barney finishes first, and replaces foo.c
with his version.
o Then Betty finishes and replaces foo.c
with her version.
§
Her version does not
have Barney's changes.
§
Unless Barney has a copy
somewhere, his changes are lost.
§ May require various new tools installed (ftp, sftp, scp, …)
There are many such tools, the first of which were
simply shell scripts on ancient Unix boxes such as VCS
however the modern implementations are both robust and very stable to prevent
code loss.
Key features provided by all major source code managers:
o Needed to allow better management policy
o The basic means of getting the central code to you
o Generally a check in will tell you if something you modified
conflicts with something else that has been changed since you last checked out
(resolution varies based on tool)
o After a branch is done being worked on (feature complete) you need
to merge it back into the main branch
o If you think an error appeared 10 revisions ago you can easily get
that code and test it
Most common ones today are CVS and SVN
o Good
o Very well established and widely used
o Many CVS like kits are available
§
TortoisCVS is a common Windows variant
o Supports modules
·
Bad
o Slow
o No good integrated diff
o Requires a CVS server
§
Can be difficult to
administer
o Can only be distributed with RSYNC
o Good
§
Supposed to be, and is,
CVS done right
§
It supports more logical
command functionality than CVS
o Bad
§
It can be argued that
the idea for CVS is flawed so CVS fixed is still flawed
§
Again not distributed
naturally
§
Also requires a server
where there is no official way to setup layout
§
However both CVS and SVN
suffer from the listed issues and simply aren’t good for every situation
Git is the made for purpose replacement of BitKeeper
as source control for the Linux kernel. It was developed from the ground up to
support the wide development from thousands of developers simultaneously.
Some quick technical info:
o This means that everyone has a full copy of the repo
o Each person can simultaneously act as a server and a client
o Servers are just git repos that everyone
syncs with
o HTTP: Slow, and anyone in the middle can see everything
o HTTPS: Slow, but encrypted transfers
o SSH: Fast and encrypted. But you must set up SSH keys
In the old days, most version controls used a
single branch. This is equivalent to using one folder for all code done by
every user. This does have drawbacks though which branching hopes to fix.
To illustrate this, we will use the example of the development of a video game. A video game could be said to usually have the following components and more:
§ Core engine
§ Graphics
§
Networking
Taking the world of a single branch, each of these teams would make development changes directly to the codebase immediately. This many issues for a large scale project though such as:
The answer is branching. Each team member has their own branch, along with each team having their own as well. This solution is surprisingly elegant; assume the following scenario. We have a dev called Bob that is part of the Graphics team. Bob would have the following for his branches:
Take our friend Bob again. In the beginning of a dev day, Bob would first pull all changes from others in
their group. To do this, they would execute the following commands:
§ git pull - Grabs all new changesets from the main repo
§
git merge Graphics-dev -
Merges all changes from the group repo with the local repo
At this point they would go through all the dev processes, changing files and such. Then they need to
commit the local changes to the repo:
git commit -a -m “commit message”
‘-a’ automatically commits all changed files
‘-m’ sets the message for when it’s
committed to the repo
If any new files are added, then this needs to be
run instead:
git add –A
Finally, after all the changes are made, Bob must
merge this back into the group repo:
git checkout Graphics-dev - Moves the current repo ‘pointer’ to the Graphics-dev branch
git merge Bob-dev - Merges the changes in Bob-dev into Graphics-dev