SVN tag and branch structure
This page provides a brief explanation of how Subversion works, how Fisheye interacts with it, and examples of how to configure Fisheye to work with Subversion according to your needs.
In a Subversion repository, branches and tags can be easily copied or duplicated — this is done by creating a form of pointer or reference from one location to another, avoiding the need to duplicate a lot of information. The disadvantage of this is that Subversion repositories can be confusing to administer at times and its internal complexity can be problematic for applications such as Fisheye that need to finely process its contents. As a result, Fisheye may require some in-depth configuration with Subversion.
On this page:
Fisheye automatic presets
Fisheye provides automatic presets that match those defined in the Subversion Red Book (at http://svnbook.red-bean.com/en/1.1/ch04s07.html#svn-ch-4-sect-7.1).
If your repository structure strictly follows either of the Subversion conventions then these presets will be suitable.
To apply a preset, go to the repository configuration page (click the repository name on the 'Repositories' screen) and choose a preset from the And then Apply the Following Rules list.
However if you have defined your svn structure via the custom symbolic rules, then you should set "Use In-built Symbolic Rules" to no.
The Use Built-in Symbolic Rules checkbox applies another regex which does a deep search for trunk, tag and branch directories. If your structure exactly matches the selected symbolic rule set, then it is safe to uncheck this.
Note that the preset rules are case-sensitive – if your SVN folder structure doesn't use all lowercase naming then you will need to define your own symbolic rules based on the defaults.
See Interpreting multiple rules below.
Introduction to Subversion conventions
The most common repository structure in Subversion is to have trunk, branches and tags directories for each project, like so:
/project1/trunk/...
/project1/branches/b1
/project1/branches/b2
/project1/branches/...
/project1/tags/t1
/project1/tags/t2
/project1/tags/...
If you point your Fisheye repository at a single project root, say /project1/
, then to Fisheye, the directory structure looks like this:
/trunk
/branches
/tags
In this case, you have one single project within the repository root. On the other hand, if you point Fisheye at the repository root, you will have multiple projects visible in your Fisheye view.
Note that this example follows common conventions for repository layout, as outlined in the Subversion Red Book. If you follow these conventions, your Fisheye configuration will be simpler.
Choosing the correct configuration method
If you are unsure as to whether you can use a preset symbolic rule, or whether you need to write your own custom symbolic rules, refer to the following:
1. If you point Fisheye at your project root:
/PROJECT1
and you have the following structure at this level of the repository:
trunk
branches
tags
Then use Fisheye's built-in rules for easy, one-step configuration.
2. If you point Fisheye at the repository root, you have multiple projects and each project has the following structure:
trunk
branches
tags
leading to this structure in each project:
/PROJECT1/trunk
/PROJECT1/branches
/PROJECT1/tags
/PROJECT2/trunk
/PROJECT2/branches
/PROJECT2/tags
(and so on), then use Fisheye's built-in rules for easy, one-step configuration.
3. Otherwise, you have a custom layout.
Custom layouts
Regular expressions are required knowledge for creating custom repository layouts in Fisheye.
If you have a custom repository structure, that is your repository structure does not follow SVN conventions, you need to configure Fisheye to recognize the paths in your repository. What you are telling Fisheye is which paths within the repository are related, i.e. which are operations on the same file in different branches and which are tags of a file. You must also tell Fisheye how to determine the branch name or the tag name. Most custom layouts are variations on the one of the two standard layouts described above. The best approach to creating your custom configuration is to use one of the appropriate entries from the drop down list. This can serve as a template for you, which you can then customize. Once you have selected the appropriate template, select the "Custom" entry from the drop down list. Now, you will be able to edit the entries (or add entries).
See the examples below for more information.
How to set a custom layout
Using Regular Expressions, you can describe any custom tag or branch structure that you have. You should use one of the common layouts (from the drop down list) as a basis, firstly select it, then select 'Custom' to edit or add rules.
When looking at a file on a branch, or a file that was tagged, Fisheye needs to determine a name for the branch or tag. Fisheye does this by matching a regular expression against the file's path, and extracting the name based upon the match. Fisheye also needs a name for files on the trunk. In effect, this is the name of the trunk 'branch'.
For any file that matches a trunk/branch/tag regular expression, a logical path is calculated. Two different files with the same logical path are considered to be related. For example, using the second type of common repository layout:
- The file
project1/trunk/dir1/foo.txt
would have a logical path ofproject1/dir1/foo.txt
. - The file
project1/tags/BUILD123/dir1/foo.txt
would have a logical path ofproject1/dir1/foo.txt
and the name of the tag would beproject1-BUILD123
. - Both these files have the same logical path, and so are considered related. By looking at the revision where the directory-copy for
project1/tags/BUILD123/dir1/foo.txt
occurred, Fisheye can determine to what revision the tagproject1-BUILD123
applies.
You can add as many rules as you need. See Interpreting multiple rules below.
ルール | 説明 |
---|---|
Regex | The regular expression used to match against the start of the path. The trailing part of the path that does not match the regex is called the tail. |
名前 | An expression used to extract a tag or branch name from the regex. |
Logical Path Prefix | This is an expression used to construct the logical path. The logical path is the concatenation of the result of this expression, and the tail of the regex. |
See the examples below for more information.
Interpreting multiple rules
See also Custom layouts above.
To find which rule to apply, Fisheye creates three sets of rules and tries them in this order: branches, tags, trunk.
For each set of rules, it finds the closest match within that set. If any rule in the set matches, Fisheye will not try the next set. If multiple rules within a set match then Fisheye will use the best match. The best match is the rule with the smallest logical tail (the trailing part of the path that does not match the regex).
例
These examples show the regular expressions used for some custom configurations. If you need more information on how these examples work, please see SVN tag and branch structure on this page.
- Ideal configuration example
This shows a best-case near "zero configuration" project structure that is instantly compatible with Fisheye.
In this case, you have trunk, branches and tags as the base folders in your repository.
- Custom example 1
This shows a custom project structure and the symbolic rules required.
- Custom example 2
This shows another kind of custom project structure and the symbolic rules required.
- Fisheye customer example.
This is a real-world configuration used by a Fisheye customer.
Ideal configuration example
If your repository is organized in this way, simply select the In-Built symbolic rules option. Fisheye will then be fully connected to your repository (you do not need to write a regular expression, or choose anything from a list).
Project structure
/PROJECT1/trunk/
/PROJECT1/branches/branchname
/PROJECT1/tags/tagname
Note that this example follows common conventions, as outlined in the Subversion Red Book.
Custom example 1
Whenever you have a custom project structure in Subversion, you will need to write a regular expression.
Say you have an additional directory you use for tagging releases, which is different from the everyday tags you create in the tags directory:
Project structure
/trunk/
/branches/branchname
/tags/tagname
/releases/releasename
Symbolic rules
正規表現 | 名前 | Logical Path Prefix |
---|---|---|
|
| N/A |
|
| N/A |
|
| N/A |
Custom example 2
Whenever you have a custom project structure in Subversion, you will need to write a regular expression.
In this example, there is a "core" project area and then a number of separate plugins. the core contains its own trunk/branches/tags structure while the plugins are in a named directory which contains their trunk/branches/tags directory. We want to have the core and all the plugins visible in a single Fisheye repository.
Project structure
/core/trunk/
/core/branches/
/core/tags/
/plugins/plugin1/trunk/
/plugins/plugin1/branches/
/plugins/plugin1/tags/
/plugins/plugin2/trunk/
/plugins/plugin2/branches/
/plugins/plugin2/tags/
Symbolic rules
適用先 | 正規表現 | 名前 | Logical Path Prefix |
---|---|---|---|
trunk |
|
|
|
trunk |
|
|
|
branches |
|
|
|
branches |
|
|
|
tags |
|
|
|
tags |
|
|
|
In this example, the Logical Path Prefix has been configured to distinguish files with the same name in different plugins. For example, the file build.xml may exist in all plugins but such files are not related even though they have the same name. The Logical Path Prefix is used to tell Fisheye to which "logical group" the files belong.
Example from a Fisheye customer
This is real-world example from a Fisheye customer. This is a slightly non-standard project structure. The correct symbolic rules for this project structure are shown below:
Project structure
/trunk/PROJECT1
/branches/PROJECT1/branchname
/tags/PROJECT1/tagname
Symbolic rules
正規表現 | 名前 | Logical Path Prefix |
---|---|---|
|
| N/A |
|
| N/A |
|
| N/A |
How Subversion works
Since tags and branches are implemented via directory copies in Subversion, they are not really first-class concepts. This means that Fisheye has to determine branch and tag information by examining the paths involved in Subversion operations and matching these against branch and tag conventions used in the repository. Since these conventions are not fixed, you may need to tell Fisheye what conventions you use in your repository. By default Fisheye has some inbuilt rules which handle the most common conventions typically used in most Subversion sites. If, however, you've decided to use a custom convention, you can define custom rules to describe what your tag/branch structure looks like. These settings can be edited on the 'Add Repository' or 'Edit Repository' pages in the Fisheye Administration pages.
The symbolic setup tells Fisheye how to classify each path it encounters as it indexes the repository. Each path is classified as either a trunk, branch, tag or root path. The trunk, branch and tag categories are the normal conventions used in SCMs. The root category is used when a path does not match any of the given trunk/branch/tag settings and is mostly treated in the same way as trunk paths. For example, the branches directory itself does not belong to the trunk, a particular branch or a tag and is classified as a root path.
The symbolic settings do not exclude any paths from consideration by Fisheye. To exclude paths you should set up appropriate 'allow' rules. If your symbolic setup does not match a path, that path will be classified as a root path and processed by Fisheye accordingly.
If you change these trunk/branch/tag settings, you would normally perform a complete re-scan of the repository to ensure Fisheye's index is consistent with the settings. Fisheye will suggest this when you make changes and you can also do this manually from the Indexer option. If you don't want to re-index, you can also choose to ignore this suggestion.
For more information on tag and branch layout, see Repository Layout in the Subversion documentation, or How tags work in Subversion for more background information.
よくある質問
What is the logical path prefix?
The first part of a path, where you want to constrain to a specific origin for the paths in context.
What is the logical tail?
The last part of the path is the logical tail, that specifies the exact folders in context.
How does the logical tail affect the search?
The logical tail could be used to select every occurrence of a file called build.xml
, for example, or every folder of a given name near the end of the path.