But the first question may be: why use a version control system at all? Look at how the source is handled by the Debian package. First, we have the pure upstream source, which is often maintained by another person. The upstream author has his own development line and releases the source in snapshots (often called releases or program versions).

The Debian maintainer adds an own set of modifications, leading to an own version of the upstream package. The difference set between this two version finally ends in Debian's .diff.gz files, and this patchset is often appliable to future upstream versions in order to get the "Debian versions".

So the obvious way to deal with source upgrades/changes is using local copies, patch, different patchutils and scripts to automate all this, e.g. uupdate. However, it often becomes nasty and uncomfortable and there is no way to undo changes that you may do by mistakes.

At this point, the Subversion system can be used to simplify that work. It does the same things that you normaly would do by-hand but keeps it in an own archive (a repository). It stores the development lines of Upstream and Debian source, keeping them in different directories (different branches). The branches are wired internally (the VCS "knows" the history of the file and tracks the differences between the Upstream and Debian versions). When a new upstream version is installed, the differences between the old and new upstream versions and the Debian version are merged together.

You can create snapshots of your Debian version ("tag" it) and switch back to a previous state, or see the changes done in the files. You can store when commiting the file to the repository or place custom tags on the files ("properties") serving various purposes.