Reputation:
I have a project which consists of several services,
each in their own SVN repository and a build script that checks out each SVN repository as a folder in a single /project
directory along with a /project
level Makefile
to recursively build the whole project.
Visually it looks something like this:
/project
Makefile
/service1 # First service (SVN repository)
/.svn
/service2 # Second service (SVN repository)
/.svn
...
I am trying to convert the project into a single shareable git repository to collaborate with teammates on without removing the ability to commit back to the original SVN repositories.
My current idea is to check out each SVN repository (/service1
, /service2
, etc.) using git-svn and then create a master git repository at the /project
level to group them into a single repository. The hypothesized project structure would look something like this:
/project
/.git # Master git repository
Makefile
/service1 # First service (SVN repository)
/.git # .git directory for git-svn checkout of service 1
/service2 # Second service (SVN repository)
/.git # .git directory for git-svn checkout of service 2
...
Will this work? Is there a simpler solution?
Note: I do not have the authority to redefine the project structure or the structure of the SVN repositories.
Upvotes: 2
Views: 959
Reputation: 1328742
It can work, provided you consider /project
as a parent repository referencing the servicexx
git repos as submodules.
That way, other collaborators can reference only the parent repo, and get back all the submodules in it.
As explained in "True Nature of submodules", they can then create/checkout branches within those submodules and start modifying them.
Make sure though than one branch is dedicate for git svn dcommit
(merge back to SVN):
See "Overcome git svn caveats" and "Easy merging in svn using git-svn".
Upvotes: 1