SVN Life Cycle
In this chapter we will discuss about life cycle of a Version Control System. In later chapters we will see Subversion command for each operation.
The repository is a central place where developers store all their work. Repository not only stores files but also history about changes. Meaning it maintains history of who did changes, in which files, when and why ?
The create operation is used to create a new repository. Most of the times this operation is done only once. When you create a new repository, your VCS will expect you to say something to identify it, such as where you want it to be created, or what it's name should be.
checkout operation is used to create a working copy from the repository. Working copy is a private workplace where developers do their changes and later on submit these changes to repository.
As name suggests update operation is used to update working copy. This operation synchronizes working copy with the repository. As repository is shared by all the team other developers can commit their changes and your working copy becomes older.
Let us suppose Tom and Jerry two developers working on a project. Both checkouts the latest version from repository and start working. At this point their working copies are completely synchronized with the repository. Jerry completes his work very efficiently and commits his changes to the repository.
Now Tom's working copy is out of date. Update operation will pull Jerry’s latest changes from the repository and will update Tom's working copy.
After checkout one can do various operations to perform changes. Edit is the most common operation. One can edit existing file to add/remove contents from file.
One can add files/directories. But immediately these files/directories do not become part of repository, instead they are added to the pending change-list and become part of repository after commit operation.
Similarly one can delete files/directories. Delete operation immediately deletes file from working copy, but actual deletion of file added to the pending change-list and changes made to the repository after commit operation.Rename operation changes the name of the file/directory. Move operation is used to move files/directories from one place to another in a repository tree.
When you checkout the working copy or update working copy then your working copy is completely synchronized with the repository. But as you do changes to your working copy it becomes newer than the repository. And it's good practice to review your changes before commit operation.
Status operation lists the modifications that have been made to the working copy. As I mentioned before, whenever you do changes in working copy all these changes become part of pending change-list. And status operation is used to see the pending change-list.
Status operation only provides a list of changes but not details about them. One can use diff operation to view the details of the modifications that have been made to the working copy.
Let us suppose one has made changes to his working copy, but now he want to throw away these changes. In this situation revert operation will help.
Revert operation undo modifications that have been made to the working copy. It is possible to revert one or more files/directories. Also it is possible to revert whole working copy, in this case revert operation will destroy the pending change-list and will bring working copy back to its original state.
Conflicts can occur at the time of merging. But what is conflict ? Merge operation automatically handles everything that can be done safely. Everything else is considered as conflict. For example, what if "hello.c" file was modified in branch and deleted in another branch ? Such a situation requires a person to make the decision. The resolve operation is used to help the user figure things out and to inform VCS how the conflicts should be handled.
Commit operation is used to apply changes from working copy to the repository. This operation modifies the repository and other developers can see these changes by updating their working copy.
Before commit one has to add files/directories to pending change-list. This is the place where changes wait to be committed. With commit we usually provide a log message to explain why someone made changes. This log message becomes part of the history of the repository. Commit is a atomic operation. Meaning either whole commit succeeds or is rolled back. Users never see half finished commit.