0

At work we used SVN until now for a project (we use TortoiseSVN). For the same project, someone from another country uses GIT and made changes to it. We want those changes on our project, and to push it back to the remote project on their server. I already pulled the project and now have their version in a folder and our version in another SVN-managed folder.

Say, one of us(me) wants to sync with the GIT project. How should I merge the GIT project with my local SVN one, push it to the remove GIT server, and push further modifications that may come from us working internally with SVN?

We are still going to use SVN internally, but want to sync our project with the remote one, and push and pull with its continuous changes from both parts. This will be done with GIT.

I already pulled the GIT project locally, and now have that folder and our SVN folder, but don't know how to merge them.

Stefan
  • 43,293
  • 10
  • 75
  • 117
George Irimiciuc
  • 4,573
  • 8
  • 44
  • 88
  • 1
    Possible duplicate of http://stackoverflow.com/questions/907913/there-is-any-way-to-synchronize-git-and-subversion-repositories – AlG Jun 12 '15 at 12:03
  • The problem is that we don't want to push changes separately. We want to push our team's changes at the end of the day/week, in the form of a stable version. We want to do local versioning between us, and afterwards, one of us will push changes to the remote server. We also want to pull whatever changes are done there in the meantime, anytime, and share them between us using SVN. – George Irimiciuc Jun 12 '15 at 12:10
  • is git-svn launched locally an option? It would work, but of course you have to manage eventually the conflicts between svn and git repository. You can also do different branch for svn and git version and then merge the branches either in git or svn, in this case, git is the more adapted for merging. – pdem Jun 19 '15 at 12:24

2 Answers2

2

Just because I'm crying by blood from the previous answer

I already pulled the GIT project locally, and now have that folder and our SVN folder, but don't know how to merge them.

Use The Proper Things (tm) by The Proper Way (tm)

  1. Install and RTFM Git
  2. RTFM Git-SVN
  3. Clone SVN trunk with Git-SVN
  4. Add additional remote to this clone (parthner's Git-repo)
  5. Pull from it

Now you'll have (at least) two "branches" in your local Git-repo - trunk and foreign. At the end of day after all commits to SVN:

  • Pull from SVN
  • Pull from Foreign
  • Merge SVN to Foreign
  • Push to Foreign
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • 2
    No need to be aggressive towards other answers. Yours does not answer the "The problem is that we don't want to push changes separately." part of the question. I would obviously have recommended git-svn otherwise. – Matthieu Moy Jun 17 '15 at 09:08
1

There are multiple possible answers depending on what you are trying to do.

If you want to avoid Git because you don't want to learn a new tool, then I can only advise to reconsider. Git is the most widely used SCM these days, the basics are not that hard to learn, and they are in any case easier to learn than a Git<->SVN bidirectional bridge.

If you want to keep using SVN because you do not want to publish your local history, then learn more about Git, there are tons of features meant exactly for this use-case in Git. You don't need a separate tool for that.

If you want to keep using SVN because you have a requirement to do so internally, and you don't want to publish your local history, then you can merge manually by having an SVN checkout and a Git repository side by side. This will be more error prone and more complex than all the alternatives. At the end of the day, you would

  • git checkout to yesterday's commit (you have nothing to do if you kept yesterday's Git worktree in the same state as it was).

  • copy your SVN checkout to the Git clone, and git commit the result. This creates a commit whose parent is yesterday's commit, i.e. the common ancestor between your SVN history and the new Git history.

  • merge with the upstream Git branch. This creates a new Git commit that contains both your changes and the upstream one.

  • push the result (this contributes today's change to upstream)

  • Copy back the worktree files from Git to SVN, run svn add, svn rm when appropriate. svn commit the result (this takes the remote Git changes to your local SVN repository).

This should be relatively easy to script.

Matthieu Moy
  • 15,151
  • 5
  • 38
  • 65
  • So we have to checkout and we will get their version up to date. Then we clone that, overwrite the clone with our SVN files and then merge it back to the remote? Did I understand this right? Why do we checkout first if we overwrite their changes? Where exactly do we merge both our changes and theirs? – George Irimiciuc Jun 15 '15 at 10:16
  • I updated my answer. In any case, you have to experiment on a toy repo before doing this live, and understand what you're doing. – Matthieu Moy Jun 15 '15 at 14:08