CODEWITHSUNDEEP
gitsvn
2Parrots
2Parrots

Reputation: 33

syncing 2 different repositories

Company A is developing software and is using their own SVN

Company B also wants to work on the same software but they only know how to use GIT

Company B doesn't want to use Company A's repository

Can company B have a synced copy of company A's SVN - but in GIT so they can work on it as well?

Basically, instead of them sharing 1 repository, there would be 2 synced repositories

One commits code in SVN, the other sees it in GIT [and vice versa]

Upvotes: 1

Views: 63

Answers (1)

Wander Nauta
Wander Nauta

Reputation: 19615

GitHub has some support for accessing repositories with both Git and Subversion. While I've not personally tried it, it might be what you're looking for, provided company A is willing to switch to GitHub.

Alternatively, I guess you could use git-svn (tutorial) to have B's git talk to (a copy of) company A's svn repository. Git-svn does the closest thing to what you're describing - it creates a copy of a Subversion repository in the format git expects, which means all the regular git commands work on it.

It's not a perfect solution, though. Here's what the git book has to say about it:

The git svn tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines:

  • Keep a linear Git history that doesn’t contain merge commits made by git merge. Rebase any work you do outside of your mainline branch back onto it; don’t merge it in.

  • Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a git-svn-id entry. You may even want to add a pre-receive hook that checks each commit message for a git-svn-id and rejects pushes that contain commits without it.

If you follow those guidelines, working with a Subversion server can be more bearable. However, if it’s possible to move to a real Git server, doing so can gain your team a lot more.

Finally, you could look into this answer, which suggests using the commercial SubGit tool for a use case that looks similar to yours in reverse. I don't have experience with SubGit either, but it's marketed as a better alternative to git-svn and it could be worth checking out.

 

Really, two different teams from different companies working on the same codebase at the same time in two different SCM systems - which is what you seem to be going for - sounds like a disaster waiting to happen. From your question, I don't know enough about your case to know which would be better, but I'm sure you could try to either...

  • seperate the two companies further and have company A officially release versions to company B, and have B send back patches if needed. This could work well if B doesn't modify A's code all that often. It would also give A better control over their own code (they get to decide if they accept B's patches or not), which sounds like a useful level of bureaucracy.
  • join the two teams better and have them use the same tools. SVN really isn't that hard if you know Git well. Vice versa shouldn't be much harder.

Anyway, good luck!

Upvotes: 1

Related Questions