Should I use standard layout param (-s) for git svn when our subversion repository adheres to standard layout currently although it was not the case for most of the history?
I'm trying to import the subversion repository into git with while history.
More details
First few years the main project folders were in the root instead of trunk folder
/ - project folders in root
'- e.g. apps
'- components
/branches
/tags
/trunk - empty
After many years a migration branch was introduced and used for few additional years
/ - project folders in root
'- e.g. apps
'- components
/branches
'- migration - a long living branch used as main project work for some time
'- e.g. apps
'- components
'- few other branches (<3)
/tags
'- many tags for releases
For the past one year the current state conforms to standard layout
/ - no files, no folders in root (except trunk, branches, tags)
/branches
'- oldMigration - migration branch renamed (moved)
'- e.g. apps
'- components
'- few other branches (<5)
'- oldRoot - folders from the root moved here
/tags
'- around 150 tags for releases
/trunk
'- e.g. apps
'- components
UPDATE Just to clarify, going forward we do not plan to work (commit/checkout) with the oldMigration and oldRoot anymore. It is just that we want the history to reflect the situation how it was for the purposes of reading history log and see who changed which files and why.
In this situation, you can feed git-svn multiple directories which represent trunk, branches and tags to cover all the possibilities throughout history.
I would recommend doing it in two steps, git svn init and git svn fetch, rather than a single git svn clone to give yourself a bit more control.
In your case it would be...
git svn init --trunk=trunk/ --trunk=. --branches=branches/ --tags=tags/ ...
You may wish to try --trunk=branches/migration, but honestly I would leave that as its own historical branch (presumably later merged into the new trunk) than trying to get Git to pretend it was trunk all along.