I like this, at least the information is preserved and can be used in a git filter exercise to use it properly. This might even be a good short-term approach for svn:externals.

Can't upvote as I'm not logged in, but I believe this will enable users to fix a lot of issues that are difficult to resolve more generally.

What properties support do you need, only svn:externals or other? Do you use custom properties?


SubGit already supports transparent svn:externals translation.

To install SubGit with svn:externals translation support run:

$ subgit confugure path/to/svn/repository

Edit path/to/svn/repository/conf/subgit.conf
add the option

[translate]
  externals=true

Run

$ subgit install path/to/svn/repository

svn:externals translation can't be turned on/off on the fly,
the whole SVN repository should be translated to Git again

svn:externals properties are converted into .gitsvnextmodules file at the repostiory root,
that is recognized by SmartGit if you open your working tree with it

The file has the following format:

[submodule "module-name"] #one section per svn external, module-name is an arbitrary unique section name to identify the section
        path = src/plugins # path where external should appear relative to working copy root, always a child of 'owner' value
        owner = /  # path on which svn:externals property is set
        url = https://host/path # URL specified in svn:externals
        revision = 123 # revision from svn:externals, can be a number or HEAD (default)

#SmartGit-related options:
        fetch = :refs/remotes/svn/git-svn
        branch = /
        remote = svn
        type = dir # "dir" or "file", determines externals kind, note

See link for file format documentation: http://www.syntevo.com/smartgit/documentation.html?page=concepts-svn&highlight=gitsvnextmodules

We didn't make the option public because of 2 reasons:
1. It performs SVN requests to the external URL in order to check external kind (file/dir).
So if you have network monitoring system, it could be disturbed by these requests.
2. We have plans to implement bi-directional svn:externals <-> Git submodules instead.

Mostly svn:externals. I was not aware of the translation for svn:externals, that is interesting. I do think that others may use properties that are not translated (not sure what this would be, but I've seen people using non-standard issue tracker properties for example).

What is the timeline for the bi-directional conversion? I'll likely give the current option a shot just to see how it works. We are still in the evaluation stage, but I think if there was a high-fidelity translation, we would buy a license during our conversion to git. svn:externals is one part of this and more automatic history detection across projects is the other.

Hello,

The undocumented way of translating svn:externals to smartgit-specific submodule files that Dmitry have described is already working two ways. Set translate.externals=true option before running 'subgit install' and each Subversion external definition will be translated to a submodule file, like this:

[submodule "module-name"] #one section per svn external, module-name is an arbitrary unique section name to identify the section
        path = src/plugins # path where external should appear relative to working copy root, always a child of 'owner' value
        owner = /  # path on which svn:externals property is set
        url = https://host/path # URL specified in svn:externals
        revision = 123 # revision from svn:externals, can be a number or HEAD (default)
        ...

You may change url and revision values and commit file back - modifications of this file will be translated to the modification of svn:externals property.

And, to process this file as a Git submodule, you would need to use SmartGit program - it will create a Git repository and you'll be able to use standard Git to work with the submodule, except for the push command, for which you'll need to use SmarGit.

We plan to implement "pure" svn:externals support that will require no external software like SmartGit, and will translate external property to the native Git submodule files. However, this is a large task that definitely will take a while, I wouldn't expect it to be completed till Q2 2013.

Translation of the cross-project branch copies is not that complicated (though there might be some not yet known issues) and this we'd probably implement till the end of this year. We'd not so far make it the highest priority, but I hope it wouldn't take much time to add this feature to the translation engine.