Introduction and practice of SVN branching and merging---command line

• Write in front
• Some of the relevant concepts and principles
• Best Practices for branching development
• Merged classifications
• Merging operations in Eclipse
• Related Resources

Write in front

This article is a presentation of the concepts, processes, and practices of SVN branching and merging, which are suitable for readers who have a basic understanding of versioning and want to understand how SVN branches and merges are used.

The SVN version corresponds to a minimum of 1.5, because many of the features of the branch and merge are 1.5 (release notes).

Some of the relevant concepts and principles

• The branch (branch) and tag (tag) are only replicas (copy) for SVN and have no other meaning. The meaning of branching and tagging is what we give to people.
• The SVN copy is implemented by "cheap copies", which creates a copy of a hard link in Unix-like form, where the consumption of space and time is fixed and small, so there is no need to worry too much about replicas and cause performance problems.
• The SVN file store is implemented by the difference (diff), the underlying storage method is two: 1, Berkeley DB, the full save the latest version of a file (revision), the old version through the reverse difference (reverse diffs) to obtain. 2, FSFS, as opposed to BDB, complete save the initial version of a file, subsequent versions are obtained by positive differences. Of course, to avoid the performance degradation caused by too many versions, SVN also uses "Skip-deltas" to reduce the number of versions that need to be traced.
• The SVN attribute can be attached to files, directories, and versions (revision). The properties of files and directories are similar to the contents of a file, and are recorded in the repository, such as a comment on each commit, which is actually an attribute of the version svn:log. Properties that begin with "SVN:" are reserved by the system, and users should not customize such properties.

Best Practices for branching development

• When doing development on a branch, you must periodically synchronize the branch with the backbone to avoid a serious conflict (confict) when the merge back to the trunk occurs after the development is complete.
• Before merging, all local modifications on the working copy are processed to facilitate rollback (revert) when the merge fails.
• When merging, pay particular attention to new/delete operations, as many conflicts are caused by such operations.
• After completing the functionality of a branch and merging it back into the trunk, discard the branch and follow up with the new branch for the development of other features. Of course, there are ways to continue using the branch.

Merge classification 1, from trunk to branch

SVN code

1. SVN merge [-R M:n] ^/trunk

Suppose "^/trunk" is the URL of the trunk, and the current directory is the working copy of the branch. This command synchronizes the most recent modification of the skeleton to the current working copy, which keeps the branch in sync with the trunk. SVN records the version number that the current working copy has been merged with by using the Svn:mergeinfo property, and then chooses the appropriate (eligible) version to merge at each merge. Of course, you can also manually specify the merge version m to n modifications.

2. From branch to trunk

SVN code

1. SVN merge--reintegrate ^/branches/quota

Suppose "^/branches/quota" is the URL of the branch, and the current directory is the working copy of the trunk. This command compares the latest version of the branch (@HEAD) to the latest version of the trunk, implementing the difference to the current working copy, which is used to merge the work done on the branch back into the trunk.

Once a branch has been merged back to the trunk using--reintegrate, if it continues to develop on that branch, it will default to include the previous reintegrate modifications, which are already done on the branch, when the changes to the trunk need to be synchronized, which can often lead to conflicts. This is also one of the reasons for the last recommendation in the previous best practices. Of course, it is also possible to make this branch available, which requires the use of the third merge below.

3. Records only Merge

SVN code

1. SVN merge-c --record-only ^/trunk

Assuming that the current directory is a working copy of a branch, the command marks version 25 of the skeleton as being merged into the current working copy, but does not make a substantial merge, so that the next time the trunk-to-branch is merged, the revision is skipped, avoiding any conflicts caused by repeated implementations. In fact, this merger is to change the svn:mergeinfo only, but the direct modification is too dangerous, so a so-called merger to standardize operations.

Merging operations in Eclipse Subclipse

There are two more popular SVN plugins in Eclipse: Subclipse and subversive, and there are a lot of discussions about both, like here. This article only describes Subclipse.

Subclipse is the interface for merging operations, which corresponds to synchronizing version 8-to-date changes on the trunk to the working copy Pearbranch, which is the branch Branches/quake. Here are a few questions to find:

• Automatic merging is not possible and the version number must be specified manually.
• Cannot make records-only merges
• cannot be directly merged with--reintegrate

CollabNet Merge Client

The Subclipse of the above should be due to the fact that the Subclipse default merge implementation was based on SVN 1.4, when there was no svn:mergeinfo 、--reintegrate and--record-only. To support these 1.5 new features, you can install the CollabNet Merge Client.

The CollabNet merge Client is an optional feature of Subclipse, which is actually an enhanced merge implementation that supports new features, as shown in the following advantages:

• Support Merging information auto-tracking and auto-merging
• Supports--reintegrate and--record-only
• The working copy can be checked before merging

Related Resources

SVN Design Ideas

Mainly see bubble-up Method This section, is the basic principle of revision.

Introduction and practice of SVN branching and merging---command line