On Mon, Oct 01 2018, Jose Gisbert wrote: > Dear members of the Git community, > > The enterprise I work for is planning to switch from svn to git. > > Before the complete switch to git we have decided to implement a scenario > where the two SCMs live together, being the svn repository the reference. We > also want this scenario to be transparent for both SCM users. > > I read the articles referenced at the end of the email and I come to the > following solution. > > My proposal consists to import the svn repository to git using git svn and set > receive.denyCurrentBranch to updateInstead. Then install pre-receive and > post-receive hooks and set that repository as the central repository for git > users. > > The pre-receive hook does git svn rebase and, if there is an update at the svn > repository, rejects the push and instructs the user to do git pull. The > post-receive hook does git svn dcommit to update the state of the svn > repository, then instructs the user to do git pull too. > > Both scripts check the changes pushed are made at master before doing anything > and exit after performing these tasks. branches.master.rebase is set to merges > at the user repository to avoid the histories of the central and the user > repositories diverge after doing git svn dcommit. > > However I'm stuck at this point because the pre-receive hook it's not allowed > to do git svn rebase because update refs are not allowed at the quarantine > environment. I was sure that I tried this solution with a past version of git > and it worked, but now I doubt this because the restriction to update refs at > quarantine environment was delivered at version 2.13, that dates from April > 2017, if I'm not wrong. > > I don't know if this solution could be implemented or is there a better way to > accomplish this kind of synchronization (I tried Tmate SubGit, but it didn't > work for me and I don't know if we will be willing to purchase a license). > Could you help me with this question? > > I come here asking for help because I think this is the appropriate place to > do so. I apologise if this is not the case. Any help is welcome. If anything > needs to be clarified, please, ask me to do so. I can share with you the > source code of the hook scripts, if necessary. A very long time ago I had a similar setup where some clients were using git-svn. This was for the first attempt to migrate the Wikimedia repositories away from SVN. There I had a setup where users could fetch my git-svn clone, which was hosted on github, and through some magic (I forgot the details) "catch up" with their local client. I.e. there was some mapping data that wasn't sent over. But users would always push to svn, not git. I think if you can live with that you'd have a much easier time, having this setup where you push to git and you then have to carry that push forward to svn is a lot more complex than just having the clients do that. GitHub also has a SVN gateway, that has no open source equivalent that I know of: https://help.github.com/articles/support-for-subversion-clients/ Maybe that's something you'd like to consider, i.e. fully migrate to git sooner than later, and for any leftover SVN clients have them push to a private repo on GitHub. Even if you only keep that GitHub repo as a bride during the migration and host Git in-house it'll be a lot easier with git as a DVCS to continually merge in those changes than pulling the same trick with a centralized system like SVN.
