Tortoise SVN Quick start Manual – Understanding Subversion
Posted on 10. Apr, 2009 by rafaelv in Tortoise SVN (Subversion)
Before I get into exactly how to use Tortoise SVN, I want to cover some basics on Subversion so you understand how it works.
Subversion is a version control system, it works by keeping a central “repository” of your source code which people can pull from to their local computers in order to access their source code and stay in sync. with their fellow workers.
Subversion used the Copy-Modify-Merge model of version control explained here:
In this model, each user’s client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are
merged together into a new, final version.
The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.
Here’s an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally’s changes don’t overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository.
But what if Sally’s changes do overlap with Harry’s changes? What then? This situation is called a conflict, and it’s usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he’ll be
able to see both sets of conflicting changes, and manually choose between them.
Note that software can’t automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes (perhaps by discussing
the conflict with Sally!), he can safely save the merged file back to the repository.
——-
A svn commit operation can publish changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files’ contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit.
In the repository, each commit is treated as an atomic transaction: either all the commits changes take place, or none of them take place. Subversion retains this atomicity in the face of program crashes, system crashes, network problems, and other users’ actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.
A nice way to visualize the repository is as a series of trees. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a “snapshot” of the way the repository looked after each commit.
Unlike those of many other version control systems, Subversion’s revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit. When a Subversion user talks about “revision 5 of foo.c”, they really mean “foo.c as it appears in revision 5.” Notice that in general, revisions N and M of a file do not necessarily differ!