Moving from SVN to Git in 1,000 easy steps

http://codeascraft.etsy.com/2011/12/02/moving-from-svn-to-git-in-1000-easy-steps/

by gavingmiller • 15 years ago

194 64 15 years ago

codeascraft.etsy.com

v21• 15 years ago

It's really excellent to read a guide on this kind of thing that focuses on the difficult human factors rather than the easier technical ones.

whalesalad• 15 years ago

Moral of the story: If you're on SVN right now, abandon it as soon as possible. Moving even a 2000 commit repo is no fun, especially when there are more developers involved.

jonstjohn• 15 years ago

I read it as Moral of the story: don't switch from SVN unless you have good reason OR small team with not a lot of commits.

urschrei• 15 years ago

The moral of any story involving SVN is: "Switch from SVN".

jordan0day• 15 years ago

That wasn't the moral of the story at all!

"If you can deal with your current source code system, do not go through this pain. Seriously. This was a long, painful process for us. Over the years, many tools, systems, and processes had become deeply intertwined with our subversion installation. That said, if your team is small, or your source control system isn’t tied into anything, go for it! Just do it as soon as possible – the only time better than today was yesterday."

The first half of that paragraph basically says that it very well might be more painful to switch to git than it is to keep using your existing system.

JoshTriplett6• 15 years ago

It also says, though, that if you want to switch, switch now, not later.

oinksoft• 15 years ago

Hm, I've run many a 5000+ revision subversion repository through git-svn and had no issues. I'm not a git evangelist, but the tools for migrating from subversion are pretty good.

Tobu2• 15 years ago

My usual way of interacting with any svn repository is to run the entire history through git-svn, a command which takes all of five seconds to issue. There are a few extra niceties to consider when the switch is permanent, like setting up an AUTHORS identity map for the import and maybe gathering public keys for a gitolite, but the tooling side is entirely painless.

j_col3• 15 years ago

Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow:

1. Commit my code to the central repo.

My new and "improved" Git workflow:

1. Commit my code to my local branch. 2. Push my local branch to the central repo.

As we're using Git as a centralised source control anyway, what is this extra work saving me over using a "traditional" centralised source control? In other words, what's the point in using a decentralised source control system in a centralised manner, and how many teams are truly using Git in a decentralised manner?

jlongster• 15 years ago

It's saving you because you can freely commit without ever running into a conflict suprisingly.

Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.

j_col3• 15 years ago

I could commit pretty freely using Subversion or Perforce to. As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Reading the original article, it seems his reason for switching to Git can be summed up in one word: Github.

sixbrx• 15 years ago

You can also freely branch and merge between your own private branches, without making everybody else see these numerous branches polluting the file hierarchy of the central repo.

More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.

tikhonj• 15 years ago

For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day.

Another benefit I've found--as a student with an internet connection that isn't always on--is that I can still commit without it.

It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch.

Ultimately, the reason you're not seeing much of an advantage to Git right now is because (from a user's standpoint) it's basically a superset of SVN. Once you get used to it and learn more about it, chances are you'll start improving your workflow to take advantage of more of its features. Git can basically support the same workflow as a centralized system, but it also supports other scheme.

j_col3• 15 years ago

Thanks for your comment, its the other schemes beyond a centralised workflow that I have not arrived at yet, as I'm new to Git and not finding it friendly so far (despite years of experience with other systems), I probably just don't get it yet ;-)

nupark26• 15 years ago

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day.

This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs.

Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit.

Just commit as you go along. If you're doing something that outright breaks the build or is disruptive, then create a branch -- it's not hard (see below).

> It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch.

I don't really understand why git users keep repeating this trope.

Here's my SVN branching process:

  svn cp ^/trunk ^/branches/some-branch

  svn switch ^/branches/some-branch

And then at some future time (or many future times) I can merge in the latest trunk changes (or vis versa). SVN has merge tracking, so it Just Works:

  svn merge ^/trunk

I can only assume that this idea that "branches are hard in SVN" is a relic of a time when SVN didn't have merge tracking -- the feature was introduced nearly 4 years ago.

> Git can basically support the same workflow as a centralized system, but it also supports other scheme.

It can, but with more work. I guess I could just alias 'git commit' to 'git commit && git push', but then why am I not just using SVN?

InclinedPlane2• 15 years ago

This is like asking "what's the advantage of driving an Audi S5 over a model T, don't they both get you from point A to B?"

Git is a far more advanced tool compared to SVN. It will enable you to do things that SVN is not capable of, and it will save you from trouble that would have resulted in a multi-day firedrill in SVN.

For example, with Git you can maintain local history on your desktop quite easily. Since there won't ever be conflicts, committing is effortless. But now you have the ability to rollback to a previous state quite easily, far beyond the ctrl-z capabilities of your favorite IDE.

Also, in general with Git merging your changes into the central repo ought to be easier than it was previously. If there are conflicts they'll be easier to sort out, for example.

jeltz3• 15 years ago

Agreed about conflicts. One of the things that surprised me the most with git, coming from subversion, was how much easier it was to merge code and how there were less conflicts and how they were often much easier to resolve.

I tried to do mostly branched development in subversion but gave up on that due to all conflicts.

kalid2• 15 years ago

In the basic use case (changes into a central repo), git and svn look similar. Git's power is revealed when you realize how it tracks changes individually -- it's super easy to branch and move changes around. The decentralization isn't just on a team level, it's on a per-developer level.

Let's say you have 3 bugs to fix. In SVN you might work on them 1 at a time (start to finish -- hopefully no blockers!), or descend into madness and try to work on all 3 simultaneously. In git, you'd make 3 branches and work on each separately.

Oh, a hotfix came along while you're halfway through a bugfix? In SVN, you cringe: do I manually copy my changes somewhere else and revert? Ugh.

In git, you just make another branch from your clean master, do the hotfix, and pull that change into your bug branches at your leisure. In svn, this branching is theoretically possible, but not used practically -- they are too cumbersome and manual (you need to track what changes went where, and could accidentally apply them twice).

I've written more about it here, if you're interested:

http://betterexplained.com/articles/intro-to-distributed-ver...

jeltz3• 15 years ago

Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on.

With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.

latchkey• 15 years ago

The thing I notice is that you weren't using branches with Subversion.

For about 4 years now, I've been doing branch based iterative development. This is a great way for a team of engineers to work together and have a continuous release process.

Meaning, you deploy trunk and do development on 'iterative branches' (ie: you have branches called iteration-0001, iteration-0002, iteration-0003, etc...). All works happens on the iteration branches which are then tested and merged to trunk on a regular basis as part of the release process. If you have work that spans more than one iteration, you make a branch off the current iteration.

Unfortunately, subversion has a very hard time keeping track of development that way. The reason is that if you (and your co-workers) want to work on another branch off of the iteration branches (so you don't hold up a release), then merging changes from the iteration branches into your branch become a nightmare because merge tracking on your branch has no way to know what is happening on the other branches. If you don't do it right, you can end up with a branch that can never be merged back.

The way merge tracking is handled is a central design failure of Subversion. I made a long blog posting about this a while back: http://lookfirst.com/2011/04/subversion-mistake.html

Git handles all of this beautifully.

So, while today, you might not need the extra functionality of git, it is good to have a tool which can support your needs in the future.

spc476• 15 years ago

The last time I used git in a work environment [1] we named our branches based on the tracking system ID we used. So when I saw a branch labeled US137, I could look that up in the tracking system to see what was being worked on.

Our QA team would then pull the developer's assigned branches into a QA repository, do a merge and test. We had no probems [2] with a team of half a dozen programmers across as many time zones (one in Russia) using that model.

[1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git.

[2] The problems we did have came from upper management that kept changing their minds about what to work on.

barend• 15 years ago

I've come to see the key distinction between git and SVN as:

* Old workflow: "commit code" and "share code with team" are jumbled together.

* New workflow: "commit code" and "share code with team" are separate actions.

This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN).

Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible.

It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.

pkaler• 15 years ago

You may be doing it "wrong".

My old Perforce workflow: code, code, code, code, code, code, code, code, commit

My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push

It's the difference between single-piece flow and large-batch production in Lean Manufacturing.

jinushaun2• 15 years ago

This, and branches. I rarely used branches in svn, but I branch all the time in git locally.

If you try to use git like svn, it's pretty frustrating. Seems like a lot of work for no gain. But if you embrace the git philosophy of commit early and often and local feature branches, you'll understand how git got so popular.

In svn, I often run into the situation where I'm working on a new feature, want to save what I've done (because it works), but it's not ready to check into the central repo. Then I usually do something that breaks the whole thing locally, but I have no way of undoing that change since nothing has been committed yet. I've seen svn users copy and paste entire directories just to "snapshot" their work. With git and local commits, you don't have this problem. You "save" your progress as you go along by committing it locally and when something breaks, you revert locally. Then when your feature is ready, you push the whole thing to the central repo.

JoshTriplett6• 15 years ago

> My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push

Likewise, but mine frequently looks like this: branch, code, commit, code, commit, code, commit, rebase -i, rebase branch on master, code, commit, rebase branch on master, merge, push.

ataggart• 15 years ago

Except "commit" means different things between the two examples. From the perspective of the rest of the team, they are both code+, push.

aneth• 15 years ago

While I'm sure others can address all of the many advantages of git, it's one of those things you don't realize how much you "need" it until you have it, then you take its power for granted until you are stuck using svn. Think iPad, running water, the wheel, a spreadsheet application, or any variety of things.

jtchang• 15 years ago

You guys laugh but migrating version control systems can be one of the most nightmarish projects an organization chooses to undertake. It's right alongside rewriting mainframe software (that probably has been working for 20 years) and an overhaul of the employee HR systems.

It's scary. It's fraught with pitfalls. But in the end everyone hopes the result is a better tool.

We need more of these writeups. I personally love git. I just think the learning curve is steep. Think you know git? Next day someone teaches you some fancy new command you didn't even know existed.

I think git is really taught wrong in a lot of tutorials. They never focus on workflow and determining what works for you and your team (if you have one). Once you decide on the workflow all the git commands you need become apparent.

cynicalkane• 15 years ago

It's best to think of Git not as a version control framework but as a library of functions on a directory-tree data structure (edit: with a history). With this mental model, you realize that

1) there's all kinds of crazy things you can do

2) for a given crazy thing someone's probably already done it, and if it's not too far-out there's probably a command for it.

The reflog makes uncollected garbage available to the user, meaning that if you screw up you can just roll back to an old commit, carrying with it an entire history, even if that commit is no longer referenced by the repo.

jcheng• 15 years ago

> on a directory-tree data structure

Or on a directed acyclic graph of refs; that's the definition that made everything click for me.

mattmanser• 15 years ago

Seriously? It's a VCS and that's all it is.

Your comment doesn't address the parent's comment at all. Moving VCS is hard in any team with more than a few members, especially when the change is coming from a few and not everyone.

I remember my old company moving from MS VSS to svn, all we hear was 'why, VSS works!', even though it was a nightmare compared to svn. Of course the change had a bunch of teething problems and the conservatives pointed and moaned more.

But who in their right mind would say VSS is better than SVN?

Any organisational change is hard, no matter how 'obviously' better it is.

finnw• 15 years ago

A company I used to work for attempted to migrate once and nearly gave up, but then realised it was feasible (and not very expensive) if we did not insist on preserving the history.

So the new revisions were kept in Mercurial and the old ones in CVS. A slight inconvenience for the first year, but after that nearly all of the interesting revisions were in the new system.

As for the legacy systems, they already required us to maintain Windows NT4 boxes and a no-longer-supported C compiler, so the additional overhead of a second VCS was tiny by comparison.

pnathan• 15 years ago

Migrating source code systems is intense. It's very much a superlinear scaling question - the more people involved, the more training, the more chance for errors, the more miscommunications, the more tooling needed.

Where I work, we've been doing some migrating from ClearCase to Mercurial. Pretty intense work.

ConstantineXVI• 15 years ago

We (10-person startup) actually migrated from TFS to Git a few months ago. The technical migration was mostly smooth (found a TFS->Git export tool); like many other people, the main issue's been the DVCS culture shock. I was "lucky" to come on right as we were beginning the migration (which I ended up leading by default), so I haven't had all of the TFSisms to work out of my system that everyone else did.

jinushaun2• 15 years ago

I have to agree with the article. GitHub's git tutorial is a lot more useful and easier to follow than the other git articles I found online.

My only complaint about learning git is the lack of distinction between what is a keyword and what isn't. The command line syntax is chock full of words. In particular, "upstream" was the most confusing thing for me starting out. Only much later did I realise that there was nothing special about "upstream". It's just an arbitrary name for a remote repo, but you wouldn't know that as a newbie reading these tutorials. It is only by convention that upstream has a special meaning.

Tobu2• 15 years ago

Actually, @{upstream} has a special meaning, and is a refname for the current branch's upstream. For example:

  # commits that are on the current branch but not upstream
  git log @{upstream}..
  # commits that are upstream but not on the current branch
  git log ..@{upstream}
  # the commit path between the current branch and upstream
  # (all commits are exclusive to either branch)
  git log ...@{upstream}

jarjoura• 15 years ago

We had an entire orgs source-code in one SVN repository. It was useful for moving files from one project to the next to keep history and enabled anyone in the org to easily commit to any project.

Obviously that wasn't scalable. (My inbox of commit log emails was insane.) So we transitioned to git. Plus, most of the engineers were already using git-svn. It just took someone who had a free weekend to "git svn clone" and move everyone over to that.

It was PAINFUL at first. I was one of the grumpy people, but after I got the hang of git, I am so glad we just ripped the bandaid off.

chucklarge• 15 years ago

I'm an engineer at Etsy and went through this transition. I am certainly no expert on either svn or git. To mirror closely how i used svn means i need to run a couple more git commands per push, a little annoying but no big deal.

I think the real pain comes when there are problems. How do i unfuck what i just did?. You're getting stressed out, there are people waiting on you to get your commits in. I had my flow down with svn, but now what do i do? Compound that with 100 engineers experiencing that on some level as we transitioned, it was trying.

It's true of changing any tool or workflow, though. You rely on muscle memory or run on auto-pilot and suddenly you don't know what to expect from your day.

Moving from SVN to Git in 1,000 easy steps

Related Stories