Page History

Standard Layout

As it was mentioned above, a SVN repository can contain many projects and SVN The Subversion development team recommends to follow a certain repository layout convention in which a handful of strategically named Subversion repository directories convey valuable meaning about the data they hold: “main line”, or trunk, of development; some branches, which are divergent copies of development lines; and some tags, which are named, stable snapshots of a particular line of development. Thus An SVN repository can contain many projects, each of them may have its own trunk, branches, and tags, thus commonly the recommended layout for a Subversion repository may look like:is organized in the following way:

/repository
        /project_1
            /trunk
            /branches
            /tags
        /project_2
            /trunk
            /branches
            /tags

...

        …
        /project_N
            /trunk
            /branches
            /tags

SubGit translates any given SVN project into Git repository and thus it translates SVN "main line", "branches" and "tags" to Git "master" branch, Git branches and tags respectively. SubGit supposes recommended SVN layout (unless --trunk and --layout auto are used with subgit configure command) so initial mapping layout it creates as simple as:an SVN project to a Git repository: by default, SVN trunk is translated to Git master branch, each branch from SVN branches directory is translated to a Git branch with the same name as SVN branch directory has, and each tag from SVN tags directory is translated to a lightweight Git tag. 

During the initial configuration phase, SubGit creates a configuration file and fulfills it with defaults values, and, particularly, it creates default mapping scheme:

trunk = trunk:refs/heads/master

...

branches = branches/*:refs/heads/*

...

tags = tags/*:refs/tags/*

...

shelves = shelves/*:refs/shelves/*

and this scheme matches to This default mapping reflects the recommended SVN project layout perfectly: it will translate SVN "main line" into Git "master" branch, all the maps SVN trunk to Git master branch, SVN branches and tags (that are being stored in according directories) into to Git branches and tags and will further translate anonymous . Additionally, it maps anonymous Git commits into SVN shelvesan SVN shelves directories, find more details on shelves in the blog post.

Another SVN project layout doesn't follow recommended naming convention, but follows recommended structure and meaning: that is, there are distinguishable "main line", "divergent copies" and "stable snapshots" in SVN, but each directory has a name that differs from recommended, e.g.:possible case is a layout that follows recommended SVN project structure, but doesn't follow recommended naming convention, for example:

/svn
      /repository
         /project
            /main
            /offshoots
            /snapshots

The main directory here is the represents a "main line" of development (and thus has the same meaning as trunk doesmatching to trunk in the meaning), the offshoots directory contains "divergent copies" (i.e. that is, branches), and the snapshots is for  directory contains "stable snapshots" (– that is, tags). In such case, the mapping scheme is still the same, but SVN directories name names must be changed to reflect actual SVN directories namesones:

trunk = main:refs/heads/master

...

branches = offshoots/*:refs/heads/*

...

tags = snapshots/*:refs/tags/*

...

shelves = shelves/*:refs/shelves/*

...

There might be another SVN project layout which structure rather close to the recommended layout: it follows the naming convention, but there is may be more than one directory for SVN containing SVN "divergent copies" and/or "stable snapshots", e.g.:for example:

/svn
      /repository
         /project
            /trunk
            /branches
            /bugs
            /features
            /tags
            /major_releases
            /minor_releases

The layout is near to recommended: the trunk directory is just trunk; but represents trunk, but there are three different directoires directories for "divergent copies" - – branches, bugs and features - – and the same three for - "stable snapshots" - – tags, major_releases and minor_releases. In such case the mapping scheme might look like that: To translate all the branches and tags, all those directories should be added to the mapping configuration and mapped to its own Git namespace:

trunk = trunk:refs/heads/master

...

branches = branches/*:refs/heads/*

...

branches = features/*:refs/heads/features/*

...

branches = bugs/*:refs/bugs/*

...

tags = tags/*:refs/tags/*

...

tags = major_releases/*:refs/major_releases/*

...

tags = minor_releases/*:refs/minor_releases/*

...

shelves = shelves/*:refs/shelves/*

this scheme maps all the directories, so SubGit will translate all the branches and tags to Git. Actually some SVN directories might be omitted if they are not needed in Git. E.g., if "bugs" branches are not needed in Git this line could be omitted in the mapping scheme:

trunk = trunk:refs/heads/master
    branches = branches/*:refs/heads/*
    branches = features/*:refs/heads/features/*
    tags = tags/*:refs/tags/*
    tags = major_releases/*:refs/major_releases/*
    tags = minor_releases/*:refs/minor_releases/*
    shelves = shelves/*:refs/shelves/*

Having such mapping configuration SubGit will translate all the branches and tags excluding those in "bugs" directorySubGit is able to create suitable mapping configuration automatically when subgit configure command is invoked with --layout auto and --trunk options, find more details on how to use automated mapping creation in the user manual.