SVN

The main content

Introduce the SVN

Introduction to the

Subversion SVN is an open source version control system. Subversion was developed by Collabnet Inc in 2000 and is now a project of the Apache Software Foundation, as well as part of a rich community of developers and users.

SVN is an open source version control system that manages data that changes over time. The data is housed in a central repository. The archive is much like a normal file server, except that it remembers every file change. This allows you to revert to an older version of the file, or to view the history of the file. To put it simply SVN is for multiple people working on the same project and sharing resources.

The main role

  1. Directory versioning

    Subversion implements a “virtual” version-managed file system that tracks changes to the entire directory over time. Directories and files can be versioned.

  2. Real version history

    In Subversion, you can add, delete, copy, and rename any file or directory. All newly added files start with a new, clean version.

  3. Automatically submit

    A commit action is either completely updated to the archive or not updated at all. This allows developers to set up and commit changes in logical intervals to prevent problems when partial commits are successful.

    …

The basic concept

  • Repository: A place where source code is stored uniformly
  • Checkout: When you don’t have the source code in hand, you’ll need to check it out from Repository
  • Commit: When you have modified your code, you need to Commit to Repository
  • Update: When you have checked out the source code, you can Update it to the Repository source code

The working process

Start your day

1. Download the latest code of the project team from the server. 2. If you have checked out and someone has committed the code, you can update it to get the latest code. (Update)

Go to your own branch, work on it, and submit code to your own branch every hour (many people have this habit). This is what happens when you change the code and you want to go back to the previous hour or see what you changed in the last hour. (Commit)

4, the time to go off work is coming, merge their branches into the main branch of the server, a day’s work is completed, and reflect to the server. (Commit)

Note: If two programmers make changes to the same file at the same time, _SVN can merge the changes made by both programmers. In fact, SVN manages source code on a behavioral basis, meaning that if two programmers do not make changes to the same one-liner, SVN will automatically merge the two changes. If it is the same line, SVN will prompt the file to Confict, conflict, need to manually confirm. _

The life cycle

Creating a repository

A repository acts as a centralized repository for all of the developer’s work. Repository can not only store files, but also contain the history of each modification, that is, the history of changes for each file.

The Create operation is used to Create a new repository. In most cases this operation will only be performed once. When you create a new repository, your version control system asks you to provide information to identify the repository, such as the location where it was created and the name of the repository.

Check out the

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

update

As the name implies, the UPDATE operation is used to update a repository. This operation synchronizes the working copy with the repository. Since the repository is shared by the entire team, your working copy will expire after others have committed their changes.

Let’s assume that Tom and Jerry are two developers on a project. They also checked out the latest version from the repository and started working. At this point, the working copy is fully synchronized with the repository. Jerry then did his work efficiently and committed the changes to the repository.

At this point Tom’s working copy expires. The update operation will pull Jerry’s latest changes from the repository and update Tom’s working copy.

Implement changes

Once checked out, there are a number of actions you can take to implement the changes. Editing is the most common operation. You can edit existing files, such as add/delete files.

You can add files/directories. These added directories, however, do not immediately become part of the repository. Instead, they are added to the list of pending changes until the COMMIT is performed.

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

The Rename operation changes the name of the file/directory. The move operation is used to move files/directories from one location to another in the repository.

Review of the change

When you check out the working copy or update the working copy, your working copy is fully synchronized with the repository. But when you make some changes to the working copy, your working copy will be newer than the repository. It is a good practice to review your changes before committing them.

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

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

Fixed error

Let’s say you made a lot of changes to the working copy, but now you don’t want them. The revert operation will help you.

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

Resolve the conflict

Conflicts can occur when merging. The Merge operation automatically handles things that can be safely merged. Anything else would be considered a conflict. For example, the “hello.c” file is modified on one branch and deleted on another. This situation needs to be dealt with. The Resolve operation is used to help users find conflicts and tell the repository how to handle them.

Commit the changes

The COMMIT operation is used to move changes from the working copy to the repository. This action modifies the contents of the repository, and other developers can view these changes by updating their working copy.

You must add files/directories to the changelist before committing. The list records the changes that will be committed. When committed, we usually provide a comment explaining why the changes were made. This comment will also become part of the repository’s history. COMMIT is an atomic operation, meaning either a complete Commit succeeds or a failure rollback. The user will not see half a successful submission.

Install the configuration

download

https://www.visualsvn.com/downloads/ (server)

http://tortoisesvn.net/downloads.html(Client)

Finally, download the completed installation package

The installation

Installing VisualSVN Server

  1. Double-click the installer visualsvn-server-4.2.1-x64.msi
  2. Check the check box to agree, then select Next, and select Upgrade
  3. Select the default configuration and select Next
  4. Set the installation path of the server, the storage directory and port of resources
  5. Using the default configuration, select Next
  6. If this popover appears, select Ignore to Ignore it
  7. Wait for the installation to complete, check the check box, and then select Finish
  8. If the following window appears, the installation is successful

Install TortoiseSVN

  1. Double-click the installer on TortoiseSVN-1.13.1.28686-x64-svn-1.13.0.msi
  2. Select Next, then Command Line Client Tools, and select Next
  3. If you want to install TortoiseSVN on the TortoiseSVN button, click Command Line Client Tools
  4. If you want to Install TortoiseSVN, click on the Install button
  5. After the installation is complete, simply select Finish
  6. In any blank space, right click, the following content appears, the installation is successful

configuration

Note: the server side needs to provide IP, port, account, password for the client to use. It has the following configuration

Set the IP and port

  1. Open the Server, click VisualSVN Server and select Configure Authentication Options…

  2. Set the Server Name. It is recommended to use the current IP

    The Server name can be set to 1.127.0.0.1 (locally accessible only) 2. By default, you can view the current IP: Open the DOS window (Windows+R key), type ipconfig, and press enter

New account password

  1. Right-click on the left-hand menu User and select Create User
  2. Set the user’s account and password

The new grouping

  1. Right-click Group and select Create Group…
  2. Set the group name, and add users to the group

Use the SVN

New repository

  1. Select Repositories, and select Create New Repository…
  2. Select Default Settings, Select Next, and Set the Repository Name
  3. Set the repository directory (select any option)
  4. Set access to the repository (here set read/write access for all SVN users)
  5. Warehouse creation completed

Checking in the project to SVN (import)

  1. Copy the address of the remote repository
  2. Select any project, right click on it and select Import from TortoiseSVN
  3. Paste the warehouse address copied in the previous step into the address bar
  4. Choose Permanent Acceptance
  5. Enter the user account and password
  6. Import success
  7. Right-click warehouse, select refresh, and see the effect in server

Check out the item.

  1. Copy the remote address of the project to download
  2. In the directory where you want to retrieve the item, right-click and select SVN Checkout…
  3. Enter the remote address to set the location of the project
  4. Retrieve complete

Commit the code

  1. If you want to TortoiseSVN, right click on the file and select Add to the repository
  2. Click on the file again, right click, and SVN Commit…
  3. Submitted successfully

Update the code

  1. If the current resource is not the latest version, you can right-click in a blank space in your project and select SVN Update
  2. The update is successful

Version conflict problem

Cause of version conflict

Suppose that both users A and B update the file kingtuns.txt when the version number is 100. User A submits kingtuns.txt to the server after the modification, and the submission is successful at this time, and the version number of kingtuns.txt has already changed to 101. At the same time, user B made modifications to the file Kingtuns.txt with version 100. After the modifications were completed, the submission failed because the modifications were not made on the latest version 101. User B updates the file, and if User B and User A modify the same line of code in the file, there will be A conflict

Version conflict phenomenon

When a conflict occurs, Subversion saves all versions of the object file (the last updated version, the currently obtained version (that is, the version submitted by someone else), its own updated version, and the object file) in the current working directory.

Assume the file name is kingtuns.txt

The corresponding file names are:

​ kingtuns.txt.r101

​ kingtuns.txt.r102

​ kingtuns.txt.mine

​ kingtuns.txt

Changes from different users are also marked in the target file.

Version conflict resolution

scenario
  1. Now both users A and B are updating the project files locally.

    User A

    User B

  2. The original contents of the hello.txt file in the project were:
  3. User A modifies the file and adds the content “User A modifies the content” and submits it to the server after completion
  4. User B modifies the file and adds the content “User B modifies the content”, which is submitted to the server after completion
  5. B The user is prompted as follows when submitting the update to the server
  6. B When you submit files to the server, you will be advised that the version is expired: You should first update the version from the repository, then resolve the conflict, then perform SVN Resolved, and then check in to the repository. After the conflict is resolved, Subversion will need to be informed of the conflict resolution using SVN Resolved so that updates can be submitted.
Three options for conflict resolution
  1. Discard your update, use SVN Revert (roll back), and commit. No SVN Resolved required in this manner
  2. Give up your own updates and use someone else’s. Overwrite the target file with the most recently obtained version, perform Resolved Filename and commit (select File — Right — Resolve).
  3. Manual resolution: When conflicts occur, manually update the target file after communication with other users. Then execute the Resolved Filename to resolve the conflict, and finally commit.
Resolve the conflict
  1. In User B’s current directory, right-click and select “SVN Update” to perform the “Update” operation
  2. A conflict occurred in the hello.txt file in user B
  3. On the file in conflict (select File – Right-click Menu – TortoiseSVN – Edit Conflicts)

  4. Open the Edit Conflicts window

    The possessory window is the current latest version on the server, the Mine window is the local modified version, the Merged window is the Merged file contents
  5. To Use the server version, select the difference content in the possposser window, right-click, and select Use this text block.

    Similarly, if you want to Use a local version, after negotiation, right-click on the Mine window and select Use This Text Block.

  6. When you’re done, select ‘Mark as Resolved’, then ‘Save’ and close the window
  7. At this point, the current conflict is resolved and you can again select “SVN Commit” to Commit the file

    Note: If you want to delete a file from the folder you want to use, click — right button — TortoiseSVN — Resolved. If you want to delete a file from the folder you want to use — Resolved Then you submit the document.

How to reduce the complexity of conflict resolution
  1. Submit documents as soon as they are edited. Frequent submissions/updates reduce the probability of conflicts occurring and the complexity of resolving them when they do occur.
  2. When submitting, write a clear message so that you can find out the reason for the user’s update later. After all, as time goes by, the reason for the original update may be forgotten
  3. Develop a good habit of using SVN every time is to submit, then update. When you open it every morning, you first need to get the latest version from the repository. All edited documents must be submitted to the repository before the end of the day.

The IDEA integration uses SVN

Configure the SVN environment

  1. File — > Other Settings (global configuration; Settings is local) — > Version Control — > Subversion

  2. Configure SVN

    When you TortoiseSVVN is in the folder you want to use, you need to add command line client tools to the Settings as well
  3. Restart the Idea

Retrieve the project

  1. Select VCS — > Checkout from Version Control — > Subversion
  2. Add the URL of the item in the remote repository
  3. Click the added URL and select Checkout
  4. Select the location of the retrieved item
  5. Select Destination to your preferences, default to other configurations, and click OK
  6. Select 1.8 Format and click OK
  7. Have checked out an item, select Yes to open it
  8. Select Add
  9. At this point, the project can be associated with the remote repository

Submit code

  1. Select VCS — > Commit…
  2. Select the file to Commit, fill in the Commit information, and select Commit
  3. After successful submission, the submission status will be displayed at the bottom of IDEA

Note: It is best to update the project before submitting it.

Update the code

  1. Select VCS — > Update Project…
  2. Default is fine, select OK directly
  3. Update the successful message

Import the project

  1. Select VCS — > Import into Version Control — > Import into Subversion
  2. Select “+” to add the address of the project import (you can manually add a folder, the files in the project will be placed in this folder, the file name is customized)
  3. Select the path to Import, and select Import
  4. Select the project to import, and click OK
  5. Check the path of the import, fill in the import information, and select OK
  6. Check whether the import was successful in the remote repository.

Version conflict problem

  1. If the resource is not updated and commits (it has been committed by another user), the commit fails
  2. At this point, an update operation is performed to update a resource that has been committed by someone else to the local area, indicating a conflict
  3. Select Merge, then the code that you want to keep, and then Apply
  4. Updated Successfully
  5. Select Commit again and the conflict has been successfully resolved