Comments on: Using Git for SVN Repositories Workflow

By: Erik Peterson

Erik Peterson — Sun, 11 Oct 2009 01:45:00 +0000

@benson
I use the same workflow you present and its worked well for me. Our svn repos don’t have much branching. So I simply keep the svn trunk in sync with git master.

By: benson margulies

benson margulies — Mon, 24 Aug 2009 00:10:20 +0000

There seems to be a giant disagreement about the safety of the following workflow:

1) git svn init with the full set of branch and tag args.
2) git branch to create a local branch
3) git checkout the local branch
4) do work
5) git checkout master
6) git merge local branch
7) git dcommit

What’s your belief?

By: stephen

stephen — Fri, 03 Jul 2009 06:42:03 +0000

Im messing around with git and svn at the minute i have an empty trunk on my svn and then i branched it to make it

trunk
branches/sprint_1

then i cloned it in git svn with branches / tags / trunk

and worked in my branches/sprint_1 then did dcommit now everything is in branches/sprint_1 on my svn as i expected but now i want to put that on the trunk, however svn head is point to branches/sprint_1

when i do
git checkout master and then git merge sprint_1 the git svn info show the url has changed form /trunk to /branches/sprint_1

any idea on how i get get /branches/sprint_1 onto the trunk when trunk is behind in the revision

cheers

By: Matthew

Matthew — Thu, 14 May 2009 05:19:10 +0000

git’s decentralized features are ideal for someone leading up the kernel of Linux. With commit-ers to linux kernal’s 22,000+ files from around the world, this makes the decentralized model of git the best fit. i.e. for Linus Torvalds Kernel group.

git implementation experience for the repository I administer has shown a full week needed for repository migration. The subversion repository(s) and all the right branches need to migrate into git. Then build scripts need factoring. The second week of migration is in progress but it looks like its pretty will complete.

In the vast majority of source code management configurations (including what I recently used successfully with svn), there needs to be a central server anyway. So what is gained by pushing the decentralized git to behave as a centralized server.

True the merging algorithms are better with git, but that’s a hard sell against the considerable costs. My git colleagues say I’m still in the anger stage of the svn grieving process: denial, anger, bargaining, acceptance.

By: Jacob Andresen

Jacob Andresen — Wed, 11 Mar 2009 19:43:13 +0000

Cool article! I did not know that git could do this. Thanks :)

By: Jesper Rønn-Jensen

Jesper Rønn-Jensen — Tue, 10 Mar 2009 12:00:06 +0000

This blog post also explains git/svn branch workflow pretty well:
Quick Start: using git (for Windows) with Google Code Project Hosting by Ariya Hidayat

By: Jesper Rønn-Jensen

Jesper Rønn-Jensen — Tue, 10 Mar 2009 11:56:27 +0000

@Simon B. thanks for your comments

–dry-run is with double dashes but WordPress has decided to change it. Thomas and I might apply a patch but it’s a very annoying default for WordPress

I changed the line to end with “…back in your working directory” — nice catch!

The last step. I changed the wording so that the workflow implied I worked on Trunk and merged from trunk to branch. I think that makes it a little easier to understand.

Besides, what I might wanted to do was creating a separate Git branch for a change — say “git checkout -b bug_35″

And then merge that branch into both trunk and the release branch.

By: Simon B.

Simon B. — Tue, 10 Mar 2009 07:08:12 +0000

Excellent article! I’m bookmarking it :)
Some corrections needed though: –dry-run is showing with only one leading dash, blamed be your blog editor?

>The last line gets your dirty files back in your repository.
Isn’t that rather “back in your working directory”?

And in the last step I’m confused. It seems you’re taking news from the svn repo’s 0.11 branch and putting them into the svn repo’s Trunk branch, together with any local changes you’ve made? But following the flow of your example before that gives an impression your changes in the git repo are not related to the from-0.11-to-trunk merge, so they really should go as separate commits? Or dcommits… :)