How are the branch names selected?

SVN Mirror
#1

Hi,

We had raised a request History missing where we discussed a case of migration of a repo from SVN to Bitbucket.
In continuation to that request , can you please help us with below query?

Regarding this case, we wanted to know if there is any pattern that is followed in selecting branch name when opting for automatic layout?
For example - When we opted for automatic layout for this migration, the list of mappings generated is as shown below-

trunk = Data/Production/Application/SurveillanceFeedProcess:refs/heads/master
branches = SVNToGITMig/ECDSurveillanceFeed/branches/*/SurveillanceFeedProcess:refs/heads/*
branches = Data/Branches/Application/ECD5.0/SurveillanceFeedProcess:refs/heads/Data/Application/ECD5.0
branches = SVNToGITMig/ECDSurveillanceFeed/*/SurveillanceFeedProcess:refs/heads/SVNToGITMig/ECDSurveillanceFeed/SurveillanceFeedProcess/*
branches = Data/Branches/Application/*/Application/SurveillanceFeedProcess:refs/heads/Data/Application/*
branches = Data/Archived/Application/*/SurveillanceFeedProcess:refs/heads/Data/Archived/*
tags = tags/*/Production/Application/SurveillanceFeedProcess:refs/tags/*
shelves = shelves/*/Production/Application/SurveillanceFeedProcess:refs/shelves/*

However, we do not see any specific pattern in which the branches are named for GIT. In one case, it is SVNToGITMig/ECDSurveillanceFeed/ /SurveillanceFeedProcess:refs/heads/SVNToGITMig/ECDSurveillanceFeed/SurveillanceFeedProcess/
In the other case, it is Data/Branches/Application/ /Application/SurveillanceFeedProcess:refs/heads/Data/Application/

We would like to know how the patterns for branch names are generated on the right hand side of the mapping(for git branch name).

Thanks

#2

Hello,

for automated branches mapping generation, add-on uses SVN history and set of heuristics to determine which SVN folder represents a branch or tag and which does not. To determine folder “meaning” add-on follows directories renames from the directory that is origin of all branches and tags (this is “/trunk” by default).

For config generation, add-on uses collected data of the following kind:

/branches/branch1 : branch
/branches/branch2 : branch
/tags/tag : tag
…

Then add-on attempts to generate minimal branches mapping configuration:

refs/heads/master = trunk
refs/heads/* = branches/*
refs/tag/*= tags/*

It gets more complicated when “origin” is a subfolder of an actual branch directory, e.g. “/trunk/component”. Then directories that are used as Git branch/tags names are a level above of the folder that have to be translated, e.g.:

refs/heads/*=branches/*/component

Also, to keep mapping small, algorithm chooses between implicit (with ‘’) and explicit (without '’) mappings. For instance in case “branches” only includes single actual branch (directory that originates from origin (e.g. from /trunk) and many other folders alongside, then there are two options:

refs/heads/* = branches/*
excludeBraches = otherFolder, anotherFolder, ...

Or

refs/heads/branch = branches/branch

Add-on make a choice basing on the number of branches vs number of unrelated directories.

In general you may consider auto-generated branches mapping as a proposal that in most cases will result in satisfactory mapping and translation. However, in certain cases, especially for projects with tangled and long history of branches and tags renames, or when you’d like to translate a particular inner directory within a branch, it then may make sense to use manually created mapping to make sure that translation result satisfies your needs.

#3

Hi,

Thank you for your inputs.
Actually, we started with the manual mappings but we were not getting history with it which is why we finally had to opt for automation layout.

Thanks