Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from SVN to Git in 1,000 easy steps

codeascraft.etsy.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Moving from SVN to Git in 1,000 easy steps

#41

Post by JoshTriplett »

jordan0day wrote: post #17
whalesalad wrote: post #3

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.

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 pos…

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

Re: Moving from SVN to Git in 1,000 easy steps

#42

Post by JoshTriplett »

Semiapies wrote: post #30
mberning wrote: post #10

Earlier quoted context omitted.

Don't live in a black and white world.

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.

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.

Re: Moving from SVN to Git in 1,000 easy steps

#43

Post by nupark2 »

tikhonj wrote: post #13
j_col wrote: post #5

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"…

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, i…

> 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?

Re: Moving from SVN to Git in 1,000 easy steps

#44

Post by nupark2 »

jeltz wrote: post #31
kalid wrote: post #25

Earlier quoted context omitted.

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…

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…

> 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.

  svn diff >patch-saved-changes
  svn revert -R .
  (work work work)
  svn patch

Re: Moving from SVN to Git in 1,000 easy steps

#45

Post by ataggart »

pkaler wrote: post #29
j_col wrote: post #5

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"…

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.

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

Re: Moving from SVN to Git in 1,000 easy steps

#46

Post by nupark2 »

JoshTriplett wrote: post #38
spc476 wrote: post #33

Earlier quoted context omitted.

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 zone…

> [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. Reminds a bit of this quote in LWN from David Woodhouse (a Linux kernel developer at Intel): 'If my corporate overlords told me I had to use my Exchange "messaging" account for external email communication, they would get a quite clear 'no' in response. My response may…

> More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else.

I set technical direction and while using git isn't a firable offense, we will never support it as the official SCM system.

The reason is quite simple: in a centralized environment, it increases costs and complexity and provides no value to offset that.

We don't want:

- People hiding their work in local branches where none of the other engineers can follow along.

- Getting massive rebased commits once every day (or worse yet, every few days).

- An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches.

Re: Moving from SVN to Git in 1,000 easy steps

#47

Post by nupark2 »

Semiapies wrote: post #30
mberning wrote: post #10

Earlier quoted context omitted.

Don't live in a black and white world.

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.

It's not even a given that git is better than subversion for most non-OSS centralized development use cases.

Re: Moving from SVN to Git in 1,000 easy steps

#48

Post by finnw »

jtchang wrote: post #15

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 l…

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.

Re: Moving from SVN to Git in 1,000 easy steps

#49

Post by pnathan »

jtchang wrote: post #15

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 l…

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.

Re: Moving from SVN to Git in 1,000 easy steps

#50

Post by oinksoft »

whalesalad wrote: post #3

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.

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.
Post reply on HN