git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Automating svn<->git gateway

From
JSJoshua Shrader <jshrader83@gmail.com>
Date
Oct 11, 2010, 20:33 UTC
Message-ID
<AANLkTikp1e72RQs3QQTqyg2m4Vk6rjz=Sv33iHAxDKoP@mail.gmail.com>
In-Reply-To
<20101011193007.GA30870@efreet.light.src>

Check out the article and third-to-last comment (as of today) at http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-since-last-month-when-i-used-svn/comment-page-1/#comment-2248

The comment (by Josh) is mine, and details how I've approached this
problem.  It's worked very well for us, and follows from a workflow
presented in Jon Loeliger's "Version Control with Git."  I haven't
messed with any hooks, but I'd imagine that wouldn't be too difficult.
 Right now, we keep a couple legacy maintenance SVN branches sync'd up
with their corresponding Git branches.  The one thing that we haven't
attempted (and don't plan on) is creating a new branch in Git that we
want to duplicate in SVN.  We're only syncing branches that existed in
SVN prior to our move to Git.  Any new branches are "Git-only."
On Mon, Oct 11, 2010 at 3:30 PM, Jan Hudec <bulb@ucw.cz> wrote:
Show 45 quoted lines
> Hello Folks,
>
> I want to set up a gateway between subversion and git, which would keep the
> master synchonized with subversion trunk, both ways, and allow working with
> any additional branches independent of subversion. For users it should behave
> as any other shared git repository accessed by push and pull. And it needs to
> be automatic.
>
> Did anybody try to set up something like this?
>
> Background:
>
> At $work, we are considering switch from subversion to git. However to avoid
> big disruptions in the work, we need to do it gradually. So the idea is to
> switch to git one by one. The people who already switch need to be able to
> test the final workflow with git, while other people still commit to the
> subversion repository.
>
> This basically rules out everybody just using git-svn, because individual
> conversions are incompatible (or is there some way to make them compatible?),
> so the people couldn't easily share their working branches.
>
> That leaves me with creating one git-svn repository and having everybody
> clone from that. Keeping the repository up-to-date from subversion side seems
> trivial (just 'git svn fetch' to it from subversion's post-commit hook).
>
> The trickier part is exporting changes pushed from the git side to
> subversion. My plan is to write a post-receive hook, that will
> 'git svn dcommit' to svn trunk.
>
> I suppose I will have to get the rewritten commit back from subversion and
> merge it back to the master. I have not yet tested whether when dcommiting
> a merge will properly keep the second parent in the rewritten commit or not.
> I can do extra merge if it does not at the cost of slightly uglier history.
>
> Thanks,
> Jan
>
> --
>                                                 Jan 'Bulb' Hudec <bulb@ucw.cz>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Previous: Jan HudecNext: Jan Hudec
Message 2 of 8 in “Automating svn<->git gateway”
  1. Jan HudecOct 11, 2010
  2. Joshua ShraderOct 11, 2010
  3. Jan HudecOct 12, 2010
  4. Jakub NarebskiOct 12, 2010
  5. Jan HudecOct 12, 2010
  6. Jakub NarebskiOct 12, 2010
  7. Jan HudecOct 13, 2010
  8. Jakub NarebskiOct 15, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.