8 ms·

Moving from SVN to Git in 1,000 easy steps

194 points by gavingmiller 15y ago

v21 15y 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 15y 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 15y 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 15y ago
    The moral of any story involving SVN is: "Switch from SVN".
    - mberning 15y ago
      Don't live in a black and white world.
      - Semiapies 15y ago
        Indeed. SVN is far from the worst source control system out there, and even as we move on to better once, it's pointedly the system that got a lot of coders into using source control.
        JoshTriplett 15y ago
        I certainly like SVN's status as a "better CVS", and from that perspective they succeeded nicely. If nothing else, SVN has a much saner repository structure that makes it possible to migrate to a modern version control system, whereas the tools for migrating a CVS repository involve huge pain and sometimes guesswork, depending on how heavily people manually hacked the repo's RCS files and how deeply they used CVS's awful branching.
        nupark2 15y ago
        It's not even a given that git is better than subversion for most non-OSS centralized development use cases.
- jordan0day 15y 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.
  - JoshTriplett 15y ago
    It also says, though, that if you want to switch, switch now, not later.
- oinksoft 15y 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.
  - Tobu 15y 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_col 15y 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 15y 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_col 15y 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.
    - jaggederest 15y ago
      > I could commit pretty freely using Subversion or Perforce to. Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause. > 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. Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did. It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
jtchang 15y 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 15y 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 15y 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.
    - xpaulbettsx 15y ago
      The key that makes things click for me is, the Commit is the most important 'unit' of Git. Tags, branches, pseudo-refs like HEAD are all just mutable or immutable (like tags) pointers to commits. http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... is absolutely worth your time if the above statement didn't trigger a lightbulb in your head
jinushaun 15y 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.
- Tobu 15y 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 15y 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 15y 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.

194 points by gavingmiller 15y ago

v21 15y 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 15y 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 15y 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 15y ago
  The moral of any story involving SVN is: "Switch from SVN".
  - mberning 15y ago
    Don't live in a black and white world.
    - Semiapies 15y ago
      Indeed. SVN is far from the worst source control system out there, and even as we move on to better once, it's pointedly the system that got a lot of coders into using source control.
      - JoshTriplett 15y ago
        I certainly like SVN's status as a "better CVS", and from that perspective they succeeded nicely. If nothing else, SVN has a much saner repository structure that makes it possible to migrate to a modern version control system, whereas the tools for migrating a CVS repository involve huge pain and sometimes guesswork, depending on how heavily people manually hacked the repo's RCS files and how deeply they used CVS's awful branching.
      - nupark2 15y ago
        It's not even a given that git is better than subversion for most non-OSS centralized development use cases.
jordan0day 15y 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.
- JoshTriplett 15y ago
  It also says, though, that if you want to switch, switch now, not later.
oinksoft 15y 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.
- Tobu 15y 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_col 15y 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 15y 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_col 15y 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.
  - jaggederest 15y ago
    > I could commit pretty freely using Subversion or Perforce to. Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause. > 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. Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did. It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

jtchang 15y 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 15y 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 15y 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.
  - xpaulbettsx 15y ago
    The key that makes things click for me is, the Commit is the most important 'unit' of Git. Tags, branches, pseudo-refs like HEAD are all just mutable or immutable (like tags) pointers to commits. http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... is absolutely worth your time if the above statement didn't trigger a lightbulb in your head

jinushaun 15y 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.

Tobu 15y 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 15y 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 15y 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.