Editing repositories.txt

Repositories

At its top level, the file consists of a number of repository matching rules:

repository iterator
{
  ...
}

repository smart_ptr
{
  ...
}
...etc...

Except for abstract repository rules, which are used only for inheritance (see below), the name following the repository keyword determines the name of the Git repository to which the rule will direct changes.

A repository rule can inherit from any number of other repository rules. The effect is as-if all the content of the “base” repository rules is replicated in the body of the “derived” repository rule.

abstract repository common_branches
{
  ...
}

repository smart_ptr : common_branches
{
  ...
}
...etc...

When two repository rules appear with the same repository name, all SVN changes matched by the two rules are directed at the same Git repository

Revision Limiting

A repository rule can begin with optional minrev and/or maxrev declarations that determine an inclusive range of SVN revisions that can be matched by the rule:

repository log : common_branches
{
  minrev 83860;
  ...
}

Sections

A repository rule can contain any number of sections, each of which declares branches, tags, or content:

repository python
{
  branches
  {
    ...
  }
  tags
  {
    ...
  }
  content
  {
    ...
  }
}

branches and tags Sections

branches and tags sections have the same format and meaning, except that branches sections direct changes to Git branches and tags sections direct changes to Git tags. Each of these sections contains zero or more “branch rules”:

repository math
{
  branches
  {
    [2957:] "/sandbox-branches/math_toolkit/" : "sandbox/math_toolkit";
  }
}

The branch rule above matches only in SVN revisions ≥ 2957, and directs every commit to an SVN path beginning with “/sandbox-branches/math_toolkit/” to a Git branch called “sandbox/math_toolkit” in the math repository [yes, Git branches can contain path components]. Note: it's important to pay attention to slashes here: the SVN path on the left should always start and end with a slash; the Git branch or tag name on the right never should.

content Sections

Each rule in a content section maps an SVN path prefix to a corresponding Git path prefix:

repository math
{
  maxrev 4374;
  content
  {
    "boost/math/" : "include/boost/math/";
    "boost/math_fwd.hpp" : "include/boost/math_fwd.hpp";
    "libs/math/";
  }
  branches
  {
    [2957:] "/sandbox-branches/toolkit/" : "sandbox/toolkit";
    [:]     "/sandbox-branches/fun/" : "sandbox/fun";
  }
}

When, as above with "libs/math/", the Git path prefix is not specified, it defaults to the empty prefix. Note: again, it's important to pay attention to slashes here. Neither SVN nor Git path prefixes should start with a slash, but both should end with a slash when the rule is intended to match directories.

What Gets Matched

To determine what will be matched in SVN by a repository rule, and where it will go in Git, combine each of the branch and tag rules with each of the content rules. So in the above example, we have:

SVN Revisions	SVN Path	Git Path	Git Branch
2957-4374	/sandbox-branches/toolkit/boost/math/…	include/boost/math/…	sandbox/toolkit
2957-4374	/sandbox-branches/toolkit/boost/math_fwd.hpp	include/boost/math/math_fwd.hpp	sandbox/toolkit
2957-4374	/sandbox-branches/toolkit/libs/math/…	/…	sandbox/toolkit
0-4374	/sandbox-branches/fun/boost/math/…	include/boost/math/…	sandbox/fun
0-4374	/sandbox-branches/fun/boost/math_fwd.hpp	include/boost/math/math_fwd.hpp	sandbox/fun
0-4374	/sandbox-branches/fun/libs/math/…	/…	sandbox/fun