Linux in a Nutshell, 6th Edition

Basic Version-Control Operations

Project data is kept in a repository, a set of directories and files managed by Subversion. Users use the svn client program to access the repository and make changes to it.

Subversion uses the copy-modify-merge development model. You make a private copy of a given project in a sandbox. (This is often called checking out a copy.) This private copy is not locked in the repository. You then make all the changes you like to the copy within the sandbox, without having to worry about what other developers are doing. As you work, you can compare your changes to the version you started with, as well as the version currently in the repository. Once you’re satisfied with the changes, you commit them, sometimes referred to as a check-in.

In the event that another developer has modified part of a file that you were working on and checked it in, when you commit your changes, Subversion notices and indicates that a conflict exists. Conflicts are marked as such in the file, and Subversion creates pristine copies of the file as it exists in the repository and of the file as you modified it, so that you can do full comparisons. Once you have resolved the conflict, you tell Subversion about it, and then commit the final version.

Subversion lets you create a development branch, a separate stream of development versions. You can periodically merge changes from the main development stream (the trunk) into your branch, and also merge changes from your branch back into the ...