Subversion Best Practices

Http://www.open.collab.net/nonav/scdocs/SVNIntro Subversion Best Practices Help IndexUsing Subversion Subversion basic research source code detection source Subversion client Subversion Best practices Advanced Subversion URL structure WebDAV and Subversion character encoding management Su Bversion Subversion access control Subversion user authentication support project Management Subversion activity report using Subversion

This is a quick start guide that can help you make the most of Subversion in your daily software development effort. use a comprehensive repository layout

There are many ways to schedule a repository layout. Because the branches and labels are normal directories, they need to be described in the repository structure.

The Subversion project is officially recommended as a "project root" approach, where the project root represents the anchor point of the project. The project root directory contains three subdirectories:/trunk,/branches, and/tags. A single repository can contain only one project root directory or multiple project roots.

Bibliography: "Select Repository Layout". Submit Logical Change sets

When you commit changes to the repository, make sure that the changes reflect a single purpose: fix specific errors, add new features, or some special tasks. The changes you commit will create a new revision number that can be used permanently as the name for this change. You can either record this revision in the error database or use it as an argument to the SVN merge to make it easier to undo this change or to move it to another branch in the future.

Bibliography: The "Subversion and Change Set" sidebar in chapter 4th. flexible use of event tracking tools

Try to create a two-way link as much as possible between the Subversion changeset and your event Tracking database: If possible, reference a specific event ID in each submission log information. When attaching information in an event (describing progress, or ending an event), provide the appropriate revision number for the change. manual tracking of merges

When submitting the results of a merge, be sure to write descriptive log information that describes the merged content, similar to the following:

Revision 3,490:4,120 of/branches/foobranch has been merged into/trunk.

Bibliography: "Manual tracking Merging" and "merging the entire branch into another branch." Understanding Mixed Revision working copies

The working copy's directories and files can have different work revisions: This feature is specifically designed to allow mixing and matching of older versions of objects with new versions of objects. But there are some questions to note: Each time the SVN commit command is executed, the working copy will have a mixed revision. The object you just submitted has the latest revision, while the other objects are still old revisions. Submissions that are not allowed include: files or directories that do not have the latest work revision cannot be submitted for deletion. You cannot commit a property change to a directory that does not have the latest working revision. SVN update unifies the entire working copy into one work revision, which is a typical solution to the 2nd issue above.

Bibliography: "Limitations of mixed revisions". Be patient with large files

Another good feature of Subversion is that there is no limit to the size of files it can handle at design time. Files are sent in a "streaming" manner between Subversion clients and servers, and typically consume less memory at both ends of the network.

Of course, there are a lot of practical issues to consider. Although it is not necessary to worry about KB-level files (for example, typical source code files), submitting large files can take a significant amount of time and space (for example, dozens of or hundreds of MB files).

When you begin, remember that the Subversion working copy stores the original copy of all version control files in the. svn/text-base/area. This means that the working copy occupies at least twice times the amount of disk space in the original dataset. Not only that, when submitting a file, the Subversion client also follows (now not be able to adjust) some algorithm: Copy the file to the. svn/tmp/(which may take some time and temporarily occupy additional disk space) between the temporary file and the original copy, or a binary differential operation between a temporary file and a blank file (if newly added). (It can take a long time to compute, although only a small amount of data will be sent over the network) to send the difference to the server and then move the temporary file into. svn/text-base/

Therefore, while there is no theoretical limit to the size of the file, you need to know that large files may require you to wait patiently while the client is processing slowly. However, you can be assured that unlike CVS, these large files do not cause the server to fail or affect other users. cannot solve the problem of copying/renaming commands

When a user performs a copy and rename operation on a file or directory, the Subversion repository tracks the history. Unfortunately, in Subversion 1.0, only one client Terminal command actually took advantage of this feature, the SVN log. A large number of other commands, such as SVN diff and svn cat, should automatically track rename history, but this feature is not implemented.

In all of these cases, the basic solution is to use ' svn log-v ' to discover the correct path in the older version.

For example, suppose you copy/trunk to/branches/mybranch in revision 200, and then commit some changes to/branches/mybranch/foo.c in subsequent releases. Now you want to compare the 80 revisions and 250 revisions of the files.

If you have a working copy of the branch and run SVN diff-r80:250 foo.c, you will see an error message about/BRANCHES/MYBRANCH/FOO.C that does not exist in revision 80. To remedy this, you should run SVN log-v in your branch or file to find out that the directory was named/TRUNK/FOO.C before revision 200, and then compare the two URLs directly:

$ svn diff http://.../trunk/foo.c@80/
http://.../branches/mybranch/foo.c@200

Mastering the time to create a branch

This is a contentious issue, and in fact it depends on the training of your software project. There are no common policies defined here, and only three common types are described here. Never branch system

(often used for initial projects that do not yet have code to run.) The user submits their daily work to the/trunk. When a user starts submitting a series of complex changes,/trunk is occasionally "corrupted" (unable to compile or failed to function test).

Advantages: This strategy is very easy to follow. The threshold for new developers to enter is very low. There is no need to learn how to branch or merge.

Cons: Unordered development and code may become unstable at any time.

Side note: In Subversion, the risk of such development is much smaller than in CVS. Because the commit of Subversion is a closed cell, the checkout or update does not receive a "partial" submission during the other person's submission. Always branch system

(often used in projects requiring extensive management and supervision.) Each user creates or operates on each encoding task in a private branch. Once the encoding is complete, the original coder, sibling, or manager will review the changes to all private branches and merge them into the/trunk.

Advantages: To ensure that/trunk can always be extremely stable.

Disadvantage: The coder is artificially segregated, causing many unnecessary merge conflicts. Users are required to perform a large amount of additional consolidation work. On- demand branching system

(This is the system used by the Subversion project.) The user submits their daily work to the/trunk. Rule #1: You must compile the/trunk at any time and be sure to pass the regression test. There will be open criticism of the authors who violate this rule. Rule #2: A single commit (change set) must be less than the maximum that the peer can review. Rule #3: If a rule #1 conflict with a #2 (such as a series of small commits that necessarily disrupts trunk), the user should create a branch and then commit a series of smaller changesets to the branch. This allows for peer review, without damaging the stability of/trunk.

Advantages: To ensure that/trunk can always maintain stability. There will be fewer problems with branching and merging.

Disadvantage: Will add some burden to the user's daily work: before each commit, must be compiled and tested.