tags:

views:

273

answers:

4

There is an open source project I want to checkout and contribute to. The main repository is SVN but I want to work in Git. Is this possible?

Most of my searches turns up guides where you move from SVN to Git (or the other way around) and dont look back.

  • If I checkout the project, make a change and push it to the branch I created on Github, how should I notify the original authors?
  • How hard is it to include a contribution made on a Git repos into a SVN repos?
  • Just comparing two revisions (my latest checkout/pull/update and my own local latest commit), generate a patch from it and send it to them; should this be considered a fallback workflow or is the standard approach?

Assume that the original authors have no interest whatsoever in learning anything other than SVN.

[Update] I dont have, nor do I want to have, commit access to the SVN repository. Im looking for workarounds for that.

[Update2] If patches are indeed my only option, are there any additional caveats I should be aware of?

+3  A: 

Yes! This is possible!

Check this post for the details: http://www.romanenco.com/gitsvn

There are three or four simple steps to make symbiosis of SVN and Git SCMs.

I worked with this technology about three month and have no any troubles. It's very cool! When your main repo in the SVN and you can make offline commits and get powerful of Git merging.

Sergey Kuznetsov
+7  A: 

Luckily there's git-svn for exactly this purpose. It enables you to use git locally while also being able to check in to SVN when you wish to do so. It's fairly straightforward and there are lots of information if you search for git-svn here or via Google.

There's a tutorial at http://flavio.castelli.name/howto_use_git_with_svn that you might want to look at first.

Edit: To generate SVN compatible diffs you can use git diff --no-prefix. Note however that this format is not compatible with TortoiseSVN. If compatibility is needed you would have to use some sort of shell script; see example here: http://mojodna.net/2009/02/24/my-work-git-workflow.html

Edit: One potential downside of git-svn is that it does not handle svn externals. You would have to handle those yourself.

Good luck!

lemonad
Yes, Ive looked some at git-svn. It looks great for fetching the updates from the original (SVN) repos. But Im mainly interested in the upstream workflow. How to properly handle and generate the patches (if thats my only option)?
mizipzor
I've now included information on generating SVN patches in my answer.
lemonad
+6  A: 

Keeping a Git repository in sync with a Subversion repository is really easy:

Clone the Subversion repository (in this simple example I am ignoring branches/tags)

$ git svn clone https://url/to/repo/trunk

Keep up-to-date with the Subversion trunk:

$ git svn rebase

Now, if you had commit access to the Subversion repo, you could push your changes:

$ git commit
$ git svn dcommit

Otherwise, submitting a patch is your only option, if the committers to the Subversion repository have no interest in using Git:

$ git diff 1cc92b96 > my_patch.patch

In this case it's obviously best not to make commits to the branch you are syncing with the Subversion repo.

Ben James
Why shouldnt I make commits to the branch Im syncing? Only because its easier to generate the diff (since I only, then, need one commit id)?
mizipzor
+1  A: 

If don't have, nor do you want to have, commit access to the SVN repository then a combination of git-svn and StGit might help. git-svn creates/updates a clone and stg maintains a series of patches on top of it (stg commands is from StGit Crash Course):

git svn clone ..

stg new invent-some-patch-id
...edit patch description...
...hack hack hack in the tree...
stg refresh
...possibly hack some more...
stg refresh    
..
stg mail

See StGIT Tutorial to get started.

NOTE: I haven't actually tried this workflow.

J.F. Sebastian
Interesting, thanks, Ill check StGit when I get home. I actually think the biggest problem here is trying to work with people who dont believe in the distributed version control systems. But they are just to manually handling patches anyway so I more and more realize that its probably the way to go.
mizipzor