1

I have my work in a git repository, some of my coworkers want to incorporate it into their subversion repository. I'm going to keep working with git, but it would be nice have a subversion repo as a remote that I can push to once in a while.

I don't plan on pulling from it ever. If this is doable, we'll have an understanding that the subversion remote is write-only from my point of view and read-only from theirs. They already have access to the git repo, and will be working there anyway (yes, it's a bit ridiculous, but I cannot change that).

Is this something that git-svn can handle?

Michael
  • 8,446
  • 4
  • 26
  • 36

1 Answers1

1

Yes. If you use git-svn to set up the SVN remote, you can subsequently use dcommit to push changes to it at will, indefinitely. If you want to enforce the workflow that only you can push to the SVN repo, that can be achieved using Subversion's access control mechanism; e.g., see How to setup access control in SVN?.

Since by default dcommit rebases the Git branch you're updating SVN from, you should consider maintaining a local branch for the purpose of publishing changes to SVN. The simplest case would be if the SVN repository need only receive commits from master and not attempt to track merges.

Community
  • 1
  • 1
Galen Charlton
  • 196
  • 9
  • 1
    But note the restrictions on what you can do on the `git` side! Much of what `git` can do just can't be expressed in SVN. – vonbrand Apr 05 '13 at 19:39
  • 1
    Indeed. If your workflow includes a lot of merging, one way to address that would be to maintain a separate local branch that is used solely for pushing to `trunk` in the SVN repository. You could then periodically merge changes into that branch, then `dcommit`, which by default would also rebase the Git branch. – Galen Charlton Apr 05 '13 at 20:41