Are there any problems if using a shared repository between SVN and Git, without git-svn?
In our distributed development teams, we have a centralized SVN repository placed remotely which is used for multiple teams committing there source code. In order to improve local performance, we have decided to use Gerrit (certainly Git instead of SVN) for our code review process, therefore we’re setting a Git’s master as a “HUB” interoperating with remote SVN repository.
- Seamless git svn setup
- How would you organize a Subversion repository for in house software projects?
- How to copy between Subversion repositories preserving properties but not preserving history
- Mirror SVN Repository
- How can I change the revision number of a repository in Tortoise SVN?
- SVNKit authentication always fails
Workaround at present
So we adopt a means looking a bit naive..
- Check out remote SVN repository.
At exactly the same directory as SVN working copy, git clone the counterpart git repository. So in this directory there’s also a “.git” besides “.svn”.
$ svn co http://remote.svn.repository/some_project
$ cd some_project
$ git clone --no-checkout git_reop ./tmp
$ mv ./tmp/.git ./ # Move .git directory to SVN working copy.
$ rm -rf ./tmp
$ git reset --hard HEAD # This is tricky to tell git I want to use this directory as unstaged.
Are there any problems if using a shared repository between SVN and Git, only by pull the Git repository into the same directory as SVN working copy without git-svn?
2 Solutions collect form web for “Are there any problems if using a shared repository between SVN and Git, without git-svn?”
No real “problem” in that both system can pretty much ignore one another.
(Except git needs to ignore any
.svn/ directory, or the unique
.svn/ folder, if you are using the latest SVN 1.8)
But your git repo must have gotten all the latest changes of
http://remote.svn.repository/some_project before being cloned within that repo (in order to be used by gerrit).
And you can’t retain author and dates with git-svn, I don’t think a manual sync could either, which means your code review system (gerrit) might not be as efficient in those condition (i.e. reviewing changes without knowing the author).
This approach gets cumbersome quickly as the mapping between Subversion revisions and their Git counterparts is implicit; it also hard to maintain proper correspondence of ignore patterns in Subversion and Git repositories.
Alternative solution would be using SubGit which is server-side bi-directional Git-SVN mirror. Below is an example on using SubGit 2.0 (currently at EAP stage):
$ subgit configure --svn-url http://host.com/svn/repo GIT_REPO # Adjust GIT_REPO/subgit/authors.txt to add author names and emails # Specify at least one username/password at GIT_REPO/subgit/passwd $ subgit install GIT_REPO
After that GIT_REPO is synchronized with your Subversion repository. You can use any Git client to work with this Git repository: all pushed commits get immediately sent to SVN.
Additionally, you can setup Gerrit server and work with it as follows:
$ git init . $ git remote add subgit SUBGIT_URL $ git fetch subgit $ git remote add gerrit GERRIT_URL $ git fetch gerrit $ git commit -m 'Work in progress' $ git push gerrit $ git push subgit
As soon as the last command is issued, corresponding Git commit is translated to SVN revision by SubGit.
SubGit is a commercial product, but it’s free as long as it’s in EAP stage. I’m one of SubGit developers.