1

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).

  1. 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?

  2. How would I include my externals as folders in my git repository?

  3. Am I approaching the situation in the wrong way?

Thank you!

Nomios
  • 151
  • 7
  • You should migrate the two svn repos to separate git repos at first, and then merge the two git repos in one git repo. – Marina Liu Nov 07 '17 at 08:14
  • 1
    I do not think it is a good idea to maintain two wildly diverged projects in the same repository, even if they initially emerged from the same codebase. This of course depends on how much they still have in common, but if they are conceptually different projects, I would rather have two repositories and apply important bugfixes concerning both by [this approach](https://stackoverflow.com/a/3816292/7598462). An alternative would be to identify common code, move it to a third repository, and maintain the shared code as a submodule of each of the other projects. – kowsky Nov 07 '17 at 08:52
  • @kowsky Applying patches is possible in svn as well, that could help. There still are significant common parts, using submodules sounds like a good idea, I will look into it. – Nomios Nov 07 '17 at 11:39
  • @Marina-MSFT - Would using `git svn clone ...` in both svn repositories result in two separate git repositories to which I can apply the approach mentioned [here](https://stackoverflow.com/questions/244695/how-to-combine-two-branches-from-two-different-repositories-in-a-single-reposito) or would the converted commits be totally different commits even if the svn commits were of the same common ancestor? – Nomios Nov 07 '17 at 12:03

1 Answers1

0

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.

Vampire
  • 35,631
  • 4
  • 76
  • 102