2

In my company we use SVN, but want to seamlessly switch to GIT in future. That's why I started to learn git-svn, which promises to serve as a frontend for svn repository.

I tried to use it with following setup:

  • SVNREPO - the master svn repository
  • GITREPO - git-svn clone of SVNREPO
  • REPO1,REPO2,... - git clones of GITREPO representing git-ers

The requirements are:

  • [ManyGitUsers] many giters can clone from/push to GITREPO
  • [ManySvnUsers] many svners commit to SVNREPO
  • [SyncHook] synchronization between GITREPO and SVNREPO can be done by hook, or manually by admin before the hook is developed
  • [NoInteraction] giters don't want to know anything about SVNREPO and vice versa
  • [NoProactivity] users solve all problems (conflicts) when they happen; they don't sync with others to avoid them

Questions:

  1. Is this setup possible with git-svn ? Suggest other if there is a better one
  2. How should I configure the GITREPO ?
  3. Will giters need to be aware of the special backend, or is everything transparent ?

So far, my experiments showed that it moreless works, but commit into SVNREPO breaks the possibility to synchronize with git. I just believe that the reason is me issuing bad commands...

Petr Kozelka
  • 7,670
  • 2
  • 29
  • 44

3 Answers3

4

There is an alternative to git-svn that looks to suite your needs: SubGit. I'm working on SubGit project, but I hope this answer is relevant and would not be considered as a spam.

SubGit is a tool that you install into your repository once on the server side. Then you'll be able to clone that repository using 'git clone' or checkout as a Subversion working copy. Git users will work just as they would work with the ordinary Git repository, no special commands are needed. Same is correct for Subversion users.

Git and Subversion sides are automatically kept in sync by SubGit.

Alexander Kitaev
  • 695
  • 6
  • 8
1

I don't think this can in long term and will cause problems.

First let me talk about how svn mirroring is done:

Usually, there is a master repo and a slave repo ( at different locations generally, hence the need). The svners, at master location checkout and commit from master. The ones at slave location checkout and commit at slave. But the actual setup is that whenever someone commits to the mirror, the commit at slave is first committed to the master and then mirrored back to slave ( svnsync). The end user is not aware of this. This makes sure that the repos are in sync. More explanation on this setup: http://www.tty1.net/blog/2007-08-26-subversion-proxy_en.html

Now, bring in Git, it becomes difficult. The thing is, there can be near simultaneous commits in bot the Git repo and the SVN repo. If the commit in SVN gets applied and the new commit comes in from Git ( which had not seen the new commit in SVN), you will be in whole lot of trouble.

The setup you can have is that all the users use git-svn to "clone" the svn repo directly. They can then use the git repo like any other svn client.

Or there is a central git repo like you mentioned ( clone with git-svn) and all the giters clone from it and push to it. There is a hook to git svn rebase and git svn dcommit from the central repo, but when things break, some one manually fixes the repo.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • you say that all users have to git-svn clone directly... but, does that really work ? my understanding is that "git svn rebase" will reapply all local git commits on top of newly received svn commit - with the effect of _changing revision numbers_ of all local commits - which always breaks the repository and prevents me to perform any further commits or pushes. Is this correct ? – Petr Kozelka Aug 19 '11 at 23:14
  • I just found this question: http://stackoverflow.com/questions/570945/git-clone-of-git-svn-tree (thanks to Related column!) providing explanation that confirms the bad news: git-svn is good for one-time migration, not for continuous use during longer transition period :( – Petr Kozelka Aug 19 '11 at 23:25
0

It works. Search / Read the documentation. Also there are tons of books that cover this.

Basically the GIT users have all the responsibiliy and everything on SVN side stays the same.

On every SVN commit GIT users have to do git svn rebase. On every GIT commit GIT users have to do git svn dcommit.

ayckoster
  • 6,707
  • 6
  • 32
  • 45
  • well if this means that git user must contantly and proactively check for svn commits, then such system is unusable. What I want is, normal workflow - I commit, commit, commmit, occasionally push/pull, without having to care. Slightly more work for conflict resolution is acceptable, but no proactivity. I still believe this is possible, but my tests show that not just the way I described – Petr Kozelka Aug 19 '11 at 20:03
  • Then perhaps you cannot use GIT like you want to. Usually SVN is the "main" repos and GIT users pull edit commit from and to SVN repos. You cannot use GIT just as another SVN, there is a reason both tools exist. – ayckoster Aug 19 '11 at 20:16
  • sure but I want to use GIT as normally - that is, without having to proactively check for remote commits. For me, distributed VCS means that I have no connection most of the time - and therefore cannot check anyway – Petr Kozelka Aug 19 '11 at 20:31
  • I'm not sure what do you mean by proactively check for commits. There is no automatic check of remote changes in normal git either. You need to do 'git remote update' or 'git fetch' manually. It should work similarly with 'git svn rebase'. Basically, you use your local git repo as a svn client. – misiu_mp Aug 22 '11 at 23:00