My team is currently working on two projects, each having a separate svn repository with standard layouts like this:
Project1/
Trunk
Branches/
module1
module2(ext)
Tags
Project2/
Trunk/
Branches/
module1
module2(ext)
Tags
Each project originated from a common ancestor at some point in time. It seems to me that using git as version control would be natural, since some bug fixes and modules should be applied to both projects. Today the best we can do is share some external modules (as module2 seen in the example), and manage those as separate svn repositories. This is fine as long as we make our externals perfectly generic, but it won't allow sharing changes in all other - different but not so different - modules (like module1).
Is there a way to migrate both projects to one git repository, having the trunk and branches of each as a branch like this:
COMMON_PROJECT_REPO
Ancestor
|____________
| \
Project1 Project2
| |
| |
__/| |\__
| | | |
| | | |
br1 | | br2
And would you consider this the right layout?
How would I include my externals as folders in my git repository?
Thank you!
If the projects are independent projects, you should not combine them in one repo in my opinion. If they are only different variants of the same project it might be ok to have them in the same repo. If not, it might be better to make the common code a library that is used by both projects.
As for the migration, you should not use git-svn
at all instaed you should use svn2git
, but the right one. See e. g. my answer at Disconnected GIT branches after migrating from SVN for more details and reasoning.
With the right svn2git
you would also be able to easily make your two SVN projects one Git repository where common commits are the same commit in the end result. With git-svn
or the wrong svn2git
this will not be the case.