SVN Lifecycle

This chapter discusses the lifecycle of a version control system.

Creating a Repository

A repository is a centralized space used to store all the work of developers. It not only stores files but also includes the history of each change, i.e., the history of changes to each file.

The Create operation is used to create a new repository. This operation is typically performed only once. When you create a new repository, your version control system will prompt you for some information to identify the repository, such as its location and name.

Checkout

The Checkout operation is used to create a working copy from the repository. A working copy is a developer's private workspace where content can be modified and then committed to the repository.

Update

As the name suggests, the update operation is used to update the repository. This operation synchronizes the working copy with the repository. Since the repository is shared by the entire team, when others commit their changes, your working copy becomes outdated.

Let's assume Tom and Jerry are two developers on a project. They both check out the latest version from the repository and start working. At this point, their working copies are fully synchronized with the repository. Then, Jerry efficiently completes his work and commits the changes to the repository.

At this point, Tom's working copy is outdated. The update operation will pull Jerry's latest changes from the repository and update Tom's working copy.

Making Changes

After checking out, you can perform various operations to make changes. Editing is the most common operation. You can edit existing files, such as adding/deleting files.

You can add files/directories. However, these added files/directories do not immediately become part of the repository; instead, they are added to the pending changes list until the commit operation is performed.

Similarly, you can delete files/directories. The delete operation immediately removes the files from the working copy, but the actual deletion is added to the pending changes list until the commit operation is performed.

The Rename operation can change the name of files/directories. The "move" operation is used to move files/directories from one place to another within the repository.

Reviewing Changes

After checking out or updating the working copy, it is fully synchronized with the repository. However, once you make modifications to the working copy, it becomes newer than the repository. It is a good practice to review your changes before the commit operation.

The Status operation lists the changes made in the working copy. As mentioned earlier, any changes you make to the working copy become part of the pending changes list. The Status operation is used to view this pending changes list.

The Status operation only provides a list of changes, but does not provide detailed information about the changes. You can use the diff operation to view the detailed information of these changes.

Fixing Mistakes

Let's assume you made many changes to the working copy, but now you do not want these changes. The revert operation will help you in this case.

The Revert operation resets the modifications to the working copy. It can reset one or multiple files/directories. It can also reset the entire working copy. In this case, the revert operation will destroy the pending changes list and restore the working copy to its original state.

Resolving Conflicts

Conflicts may occur during merging. The Merge operation automatically handles safe merges. Anything else is treated as a conflict. For example, the "hello.c" file is modified on one branch and deleted on another. This situation requires manual intervention. The Resolve operation is used to help users identify conflicts and inform the repository how to handle them.

Committing Changes

The Commit operation is used to transfer changes from the working copy to the repository. This operation modifies the content of the repository, and other developers can view these changes by updating their working copies.

Before committing, you must add files/directories to the pending changes list. The list records the changes that will be committed. When committing, we usually provide a comment explaining why these changes were made. This comment also becomes part of the repository's history. Commit is an atomic operation, meaning it either succeeds completely or fails and rolls back. Users will not see a situation where only half of the changes are successfully committed.