Life Cycle of VCS

Create Repository

As we have discussed in the previous chapter, repository is a central place where the developers store all their work and also maintain history about the changes made.

The “create” operation, as name states, it is used to create a new repository. Mainly this operation is done only once for a Project. When you create a new repository, VCS will expect you to input the details to identify it, such as where you want to create it, or what name you want to give to the repository.

Checkout

With Checkout operation, a team member creates a working copy from the repository. Working copy is a workplace of an individual team member, where they perform their changes and submit these changes to repository.

Update

Update operation updates the working copy. With Update operation, a team member synchronizes his working copy with the repository. As a team is working on the project and after doing some changes they commit their changes and your working copy becomes older. So, you have to perform the update operation.

Let us suppose John and Merry are the two developers working on a project. Now, both of them check out the latest version of project from the repository and start working on it. At this time, working copy of both are completely synchronized with the repository.

John completes his work efficiently and commits his changes to the repository.

Now Meery’s working copy is out of date. Update operation will pull John’s latest changes from the repository and will update Merry’s working copy.

Perform Changes

After checkout, a team member can perform various operations to do changes and Edit is the most common operation. Any team member can edit the existing file to add/remove its contents.

Any team member can add files/directories, similarly delete any file/directory. He/she can rename the files/directory,also move files from one directory to another. But, all these changes do not reflect in repository immediately. They’re added to the pending change list and once the commit operation performed, these changes become the part of the repository.

Review Changes

When any of the team member, checkout or update the working copy, then their working copy is completely synchronized with the repository. Now, as soon as they perform changes to their working copy, it becomes newer than the repository. And reviewing changes before commit operation is a good practice.

Here for this you can use the Status operation which lists down the modifications that have been made to the working copy using pending change list.

Fix Mistakes

After checkout, a team member perform some changes to his working copy, but now, he also makes some mistakes and to fix them, he want to throw out all the changes made by him. In this situation, he can use revert operation which revert back the modifications that have been made to the working copy.

He can revert one or more files/directories,also the complete working copy. Revert operation destroys the pending change-list and bring the working copy back to its original state.

Resolve Conflicts:

Merge operation is for merging working copy with the repository. Merge operation automatically handles everything and merge files/directories safely. But sometimes, conflicts occurs while merge operation. Everything else is considered as conflict. For example, a file was modified in branch and the same is deleted in another branch. In such situation, human intervention is required to make the decision.

Commit Changes

Commit operation is used to update the changes performed in working copy to the repository. With commit operation, a team member modifies the repository with its working copy and other team members can access these changes by updating their working copy.

Commit Operation is an atomic operation, which means either the whole commit succeeds or it will be rolled back.