May 25, 2021 SVN
This chapter discusses the life cycle of version control systems. In a later section, we'll cover the SVN commands for each operation.
The repository is the equivalent of a centralized space for all the developer's work. The repository not only holds the files, but also includes the history of each modification, that is, the history of each file change.
The Create operation is used to create a new repository. I n most cases, this operation is performed only once. When you create a new repository, your version control system lets you provide some information to identify the repository, such as where it was created and the name of the repository.
The Checkout operation is used to create a working copy from the repository. A working copy is a developer's private workspace that can be modified and then submitted to the repository.
As the name implies, the update operation is used to update the repository. T his synchronizes the working copy with the repository. Because the repository is shared by the entire team, your working copy expires when others submit their changes.
Let's assume that Tom and Jerry are two developers of a project. T hey also checked out the latest version from the repository and started working. A t this point, the working copy is fully synchronized with the repository. Jerry then efficiently completed his work and submitted changes to the repository.
At this point, Tom's working copy expires. The update action pulls Jerry's latest changes from the repository and updates Tom's working copy.
After checking out, you can do a lot to make changes. E diting is the most common action. You can edit files that already exist, such as adding/deleting files.
You can add files/directories. However, these added file directories do not immediately become part of the repository, but are added to the list of pending changes and do not become part of the repository until the commit operation is performed.
Similarly, you can delete files/directories. The deletion immediately removes the file from the working copy, but the actual deletion of the file is only added to the list to be changed and will not be actually deleted until the commit operation has been performed.
The Rename operation can change the name of the file/directory. The Move operation is used to move files/directories from one place to another in the repository.
When you check out a working copy or update a working copy, your working copy is fully synchronized with the repository. B ut when you make some changes to the working copy, your working copy will be newer than the repository. It's a good habit to review your changes before you commit.
The Status action lists the changes made in the working copy. A s we mentioned earlier, any changes you make to your working copy will be part of the list to be changed. The Status action is used to view this list of pending changes.
The Status operation simply provides a list of changes, but does not provide details of the changes. You can use the diff action to see the details of these changes.
Let's assume that you've made a lot of changes to your working copy, but now that you don't want them, the revert operation will help you.
The Revert operation resets the modifications to the working copy. I t can reset one or more files/directories. O f course, it can also reset the entire working copy. In this case, the revert operation destroys the list to be changed and restores the working copy to its original state.
There may be conflicts when merging. erge operation automatically handles things that can be safely merged. O thers will be treated as conflicts. F or example, .c "hello" file is modified on one branch and deleted on another. T his situation needs to be handled artificially. Resolve operations are used to help users identify conflicts and tell the repository how to handle them.
The Commit action is used to move changes from the working copy to the repository. This will modify the contents of the repository, which other developers can view by updating their working copies.
Before you submit, you must add the file/directory to the list to be changed. C hanges that will be committed are recorded in the list. W hen submitting, we usually provide a comment explaining why these changes were made. T his comment also becomes part of the repository history. mmit is an atomic operation, which means that either the full commit succeeds or fails to roll back. Users will not see half of the successful commits.