How are svn externals handled during the translation of SVN repo to GIT?

SVN Mirror
#1

Hi,

Can you please let us know how svn externals are handled during the migration from svn to GIT using SVN mirror?
Also, how can we make a deep copy (make a separate copy to each location) of external reference of folders or files in the repositories during translation?

Thanks

Script for conversion of SVN externals to Git submodules
#2

Hello,
by default svn externals are not handled at all. But immediately after ‘subgit configure’ command you could do one of these things:

  1. Set

    [translate]
    externals = true

option in subgit/config. This will enable bi-directional translation between svn:externals and .gitsvnextmodules file in the Git repository root. Unfortunately .gitsvnextmodules format is now obsolete. It could only be useful if you would like to write a script that would add corresponding Git submodules (or Git X-Modules — our upcoming product) into the corresponding paths with a script or manually.

  1. You could keep ‘externals = false’ but enable “other properties” translation:

    [translate]
    otherProperties = true

This will create .gitattributes file corresponding to all SVN properties not handled by other translate.xxx options, and svn:externals in particular. Again, the only reasonable usage of it is to write a script that would read such .gitattributes file and act accordingly. I don’t recommend to use this approach and if you would like to write such a script, it’s better to query the SVN repository directly.

So as you see, there’s no reasonable way to handle svn:externals preserving their semantics. There’s a reason for that. svn:externals properties points to some SVN server by some URL. In Git one cannot use an SVN repository as a kind of module directly. Even when this SVN repository is also converted by SubGit, there’re technical difficulties (e.g. such a repository doesn’t know its own URL because this information is beyond the repository scope; while svn:external contains SVN URL or its shorter version). So we didn’t implement any more reasonable support of svn externals in SubGit than that I’ve described above.

I don’t understand your second question regarding “deep copy”. Probably if you could reformulate it or describe the problem in detail, I could help you with that.

#3

I’ve noticed that your question is about SVN Mirror, not SubGit. But actually they are the same, SVN Mirror just has graphical interface and Bitbucket integration.

You can specify arbitrary SubGit options in this area:

739×390 35 KB

So my answer also applies to SVN Mirror.

#4

Hi,

Thank you for your reply.
By deep copy , we mean if we have a svn external named ‘tools’ at a location https://svn.dts.fm.rbsgrp.net/ccrp/trunk/conflicts/argon/build/tools which is displaying the content from https://svn.dts.fm.rbsgrp.net/ccrp/trunk/conflicts/common/tools , how can we get the content on the migrated git repo?

Thanks

#5

I see. I think, the easiest way to do that is to convert both repositories to Git separately. After conversion you can insert one Git repository into another one. There’re several ways to do that:

  • use Git submodules or its analogs (Git subtree, Git subrepo, etc.);
  • use some Git conversion tool (git filter-branch, reposurgeon, etc) to insert this another repository directly inside the tree;
  • use our new tool Git X-Modules — it also inserts one Git repository into another one (like filter-branch or reposurgeon) but inlike them allows to keep the module as a separate repository constantly synchronizing changes to the parent repository (i.e. repository where you insert the module). So filter-branch and reposurgeon are one-time solutions, while Git X-Modules is of continuous synchronization manner.

Actually the choice mostly depends on whether you have to keep the Git repository in sync with SVN or do you only need only one-time SVN->Git conversion. If you have to keep both Git repositories in sync with SVN, then probably Git submodules or Git subtree would be the only possible solutions (as they are client side).

If you one-time SVN->Git conversion is enough, I would recommend Git X-Modules (of course I can be biased here) or something like reposurgeon, not sure about filter-branch.