He who controls the version control, controls the past.
Version control (aka source control) is the basic level of SoftwareConfigurationManagement, upon which any more sophisticated SCM is built. At its most simple, it is a means of storing code.
Examples of source control software are:
Version control is at a finer grain than nightly backups. It should be entirely at the control of the author when a version is kept.
This is not the only difference. More sophisticated version control implies organizing the versions into a tree with branches, thus supporting parallel development. This again requires merging capabilities. Labeling comes soon handy, allowing to relate versions of different elements. Finally, different SCM systems may have restrictions to the support of various kinds of elements (e.g. binary file formats, or directories --required to manage the names of elements).
What we want is of course the share information in a collaborative way. And sharing can only be OpenClosed:
- If an artifact is not open, I must make a copy to change it. Then it is not shared anymore.
- If it is not closed, I must protect my investments against the changes somebody else could make. I keep a copy, and sharing is again gone.
VersionControl can be a basis for
SoftwareChangeManagement.
In the same vein as
ChangeManagementAppliedToWiki, we can also consider
VersionControlAppliedToWiki --
MarcGirod
Tips for selecting source code control systems:
- Make sure it will keep your source. Find people who use any system you consider and ask them how often they have lost source. Don't make excuses for the vendor even if the customers you interview admit to making mistakes. These things are supposed to protect you from your own mistakes.
- Make sure you can refactor your program. Some won't let you rename a class. Renaming a class is an elementary refactoring and if it is impossible then you should know. Don't be satisfied if you lose all history upon renaming a class.
- If you are going to work on the program for more than 1 release, make sure the system can properly support branching. Don't be satisfied if the system forces you to hash all your branches into one long stream of versions where you can't tell one branch from the other.
- Make sure that client software exists for a variety of operating systems. You don't want a source code repository that is only accessible from one particular platform.
- Make sure that the per-client licenses don't cost too much. You don't want cost to discourage installation of the client software on all developers' machines. You also don't want all users to use one account; you need to be sure every change can be tracked to a specific person.
- Make sure that the system supports multiple programming languages and development tools. You don't want all your Java code in one repository, and your C++ code in another, for example. Ideally, everyone in your organization should use the same source code repository for all projects, to allow easy sharing.
- Make sure that the system supports whatever policies you want to have for using and modifying the contents of the repository (who is allowed to check things out, who is allowed to check things in, who will be notified of changes, who will review changes, etc.).
- Prefer client/server systems over file-based ones. Systems that rely on networked file sharing are much more vulnerable to corruption due to network hiccups and computer outages, and it can be harder to arrange for a clean backup.
Discussion:
It's not the version control system that won't let you rename a class. Rather, it's the combination of a version control system that doesn't support real file renaming and a programming language which forces file names to follow class names.
It is a scandal how often these things lose your source. Write a cron job to save your source tree in a zip file. --AnonymousDonor
... and when you've lost track of which particular zip file you need from the hundreds that have been created, you have discovered the need for a proper source code control system. Just imagine you could ask the software "What changed between r1.1 and r8.5 of bignastyfile.c?"
I think he meant to save your source in a zip file in addition to using a source code control system.
With DistributedVersionControl systems, every repository you check out can potentially be a backup of the entire history. -- ScottVokes
I've been using VersionControl tools for ten years, and have yet to lose any source files. Don't be afraid of these things (but do be sure to keep backups). I trust simple file/text-based tools like CVS more than I do the database-backed tools or the ones that store things in proprietary binary forms. -- KrisJohnson
I totally agree with KrisJohnson. File/text-based tools have disadvantages but the advantages of recovering (I have lost a repository, that isn't that funny) and of portability to other tools or systems. Nevertheless you can use or build your own add-on tools. -- AndreasSchweikardt
What I expect of my perfect version control system:
- concurrency
- concurrent developing
- support of binary files (if possible)
- branching
- easy branching and merging of branches
- sub-branches
- common files of branches
- differences
- unicode support
- not only line based diff - think of minor changes in long lines
- good diff-tool (not only diffing but search for changes in that line)
- who changes that? and why?
- support for binary diff
- reorganizing / administration
- easy renaming files and directories
- file/text-based for recovering, portability and using own tools
- main repositories and sub repositories
- grouping of files not only in directories
- networking
- working offline (and good sync mechanism)
- working distributed
- rights for groups of files or directories for different users
- fast, also in the internet
- supporting groups of developers
- change management
- check-in form - required comments and fields
- check-out form - why check out the file
- information of check-outs or check-ins
- signing changes (for reviews, inspection)
- tagging versions/releases
- named check-in - check in files at different times and see it as one change
- adaptability
- programming add-ons is allowed
- own numbering of versions
- plug-ins for better checks
- CR-LF or CR replacements checks
- filtering for check-ins
Please add your own ideas ...
--
AndreasSchweikardt
External Links
See also ExtremeVersionControl ...
CategoryConfigurationManagement
Version Control