SIGNIFICANT
BITS
by Sean N Henderson
VERSION CONTROL
Much has been written about version control (VC). Here is
a bit of an introduction to those not familiar with the concept.
VC is useful to a lot people besides coders. Authors spring
to mind immediately as a group who would find VC useful.
How VC works: A file is created and edited. At some point
it might be desired to freeze, archive or snapshot (pick a
term) the file so it can be referenced or chosen over a later
version. If not using any sort of VC application, typical users
copy out the file to a similar name and stamp it using either
an index number or date. If using VC, the file gets "checked
in" initially. On subsequent editing sessions, the file
is "checked out". When a file is "checked out" for
editing, (generally) other users are prevented from making
changes to the file or else the changes create a "fork" or "delta".
Some VC apps will attempt to reconcile simultaneous edits.
Obviously, there's little or no file-locking without a VC application
and is dependent on OS and configurations.
SIMPLE VERSION CONTROL
A really simple way to VC a file is to send yourself the file
as an attachment in an email. This limits the file size, but
is one solution as is good if not around your usual system.
VERSION CONTROL ON UNIX/Linux
Most flavors of UNIX/Linux have 'sccs' built in. At the shell,
type 'man sccs' to get the low-down and a list of 'see-also'
entries. (Love UNIX for that convention.) Although not installed
by default on many systems, RCS is pretty common and much easier
to use. CVS is also popular. For myself, if I need the file's
version details included in the file, I choose sccs over RCS,
otherwise RCS winds out for being simpler.
VERSION CONTROL ON WINDOWS
Some application on Windows have version control built in.
MS Word documents can use a type of versioning inside the file.
Some may find it confusing and resort to copying out the file
to another filename.
MS has a VC system called Source Safe (hereafter MSSS). It
is launched by going to Start Menu > Programs > Microsoft
Visual Studio 6.0 > Microsoft Visual Source Safe > Microsoft
Visual Source Safe 6.0. MSSS is seems suitable for coding things
like Visual Basic programs, library files, ASP files, and other
MS proprietary files. It seems less useful for things like
general documents.
Unlike VC apps on UNIX/Linux, and typical for MS, files versioned
by MSSS are stored in a database. This is part of the what-not-where
application design philosophy that I've commented on previously.
If you're uncomfortable with files living inside a database
vs. a separate directory, consider another VC than MSSS.
Other VC apps for Windows include CVS, Borland StarTeam, Subversion,
SourceGear Vault and others. I'm looking forward to investigating
TortoiseSVN.
Keep in mind that most VC software involves some sort of daemon
or service to be running. These could be as simple as a web
server to a full-blown app server. If you're concerned about
performance overhead, choose your VC wisely.
FILES THAT ARE CANDIDATES FOR VERSION CONTROL
Any file that changes over time is a candidate for VC, especially
where the previous version of the file may still be needed.
Note that sccs can version graphic files using the utility
uuencode.
For instance, this article is produced using version control
(RCS). On websites, HTML pages could be put in VC, in particularly
the index files and other files that get 'slurped' into main
pages. The data files that feed various calendar applications
and similar get versioned so that they can be kept as small
as possible , and prevent a group of editors from overwriting
each others' changes.
Without version control, a lot of HTML and other code related
files would be bloated with commented-out code that some coders
would not be comfortable losing altogether. So using VC in
this case is a way to keep the final file as small as possible.
VERSION CONTROL GOTCHAS
It is not correct to assume that once a VC system is in place
that a team can just edit at will, and trust in the VC app
to merge the deltas seamlessly. That is still a human job.
This is especially true if the code is deep and the developer
team or group of contributors number more than 2-3 people.
For more on version control, in particular for teams or groups,
check the documentation on Subversion. |