As it was mentioned above, a SVN repository can contain many projects and SVN team recommends to follow a 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 the recommended layout for Subversion repository may look like:
/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
--layout auto are used with
subgit configure command) so initial mapping layout it creates as simple as:
trunk = trunk:refs/heads/master branches = branches/*:refs/heads/* tags = tags/*:refs/tags/* shelves = shelves/*:refs/shelves/*
and this scheme matches to recommended SVN layout perfectly: it will translate SVN "main line" into Git "master" branch, all the SVN branches and tags (that are being stored in according directories) into Git branches and tags and will further translate anonymous Git commits into SVN shelves.
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.:
/svn /repository /project /main /offshoots /snapshots
main directory here is the "main line" of development (and thus has the same meaning as
trunk does), the offshoots directory contains "divergent copies" (i.e.
branches) and the snapshots is for "stable snapshots" (that is,
tags). In such case the mapping scheme is still the same, but SVN directories name must be changed to reflect actual SVN directories names:
trunk = main:refs/heads/master branches = offshoots/*:refs/heads/* tags = snapshots/*:refs/tags/* shelves = shelves/*:refs/shelves/*
and again, this mapping scheme matches to the SVN layout perfectly and SubGit will translate all the present SVN data.
There might be another SVN project layout which structure rather close to the recommended layout: it follows the naming convention, but there is more than one directory for SVN "divergent copies" and/or "stable snapshots", e.g.:
/svn /repository /project /trunk /branches /bugs /features /tags /major_releases /minor_releases
trunk directory is just
trunk; but there are three different directoires for "divergent copies" - branches, bugs and features - and the same for - "stable snapshots" - tags, major_releases and minor_releases. In such case the mapping scheme might look like that:
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" directory.