Moving from SVN to Git in 1,000 easy steps • Hacker News Board

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

#31

Post by jeltz » Fri, Dec 02, 2011, 11:23 PM UTC

kalid wrote: post #25

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

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

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

#32

Post by jeltz » Fri, Dec 02, 2011, 11:30 PM UTC

InclinedPlane wrote: post #24

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

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…

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.

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

#33

Post by spc476 » Fri, Dec 02, 2011, 11:44 PM UTC

latchkey wrote: post #26

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

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…

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.

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

#34

Post by kalid » Fri, Dec 02, 2011, 11:46 PM UTC

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…

Totally agree. When first learning git, I got comfortable with git stash: work work, bug comes along, git stash, apply bug to master, git stash apply to get back to my state, work work. Then I started getting comfortable with branches.

Git stash is a killer feature that every developer can relate to, and highlights git's power.

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

#35

Post by jinushaun » Fri, Dec 02, 2011, 11:46 PM UTC

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.

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.

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

#36

Post by InclinedPlane » Fri, Dec 02, 2011, 11:54 PM UTC

jeltz wrote: post #32

InclinedPlane wrote: post #24

Earlier quoted context omitted.

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…

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.

One of the downsides of git (and mercurial and others) being evangelized so heavily as next generation distributed version control systems is that some of the more fundamental improvements get passed over. These are world-class version control systems, even discounting their dvcs capabilities. If you do a merge with git/hg vs svn or even perforce or TFS you'll get about as good an experience and a workflow as is possible.

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

#37

Post by mattmanser » Sat, Dec 03, 2011, 12:29 AM UTC

cynicalkane wrote: post #19

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…

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

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.

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

#38

Post by JoshTriplett » Sat, Dec 03, 2011, 12:49 AM UTC

spc476 wrote: post #33

latchkey wrote: post #26

Earlier quoted context omitted.

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…

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 also contain suggestions that they use certain other objects for purposes for which they were not designed.'

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.

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

#39

Post by JoshTriplett » Sat, Dec 03, 2011, 12:58 AM UTC

j_col wrote: post #14

tikhonj wrote: post #13

Earlier quoted context omitted.

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…

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 ;-)

One way to look at it: in some ways Git provides a framework for almost any workflow you could possibly want. It optimizes for workflows that major users of Git care about, such as the model followed by the Linux kernel and adopted by many other projects. But Git won't enforce very much structure on you; you impose that on yourself. As a result, you can use it almost exactly like SVN, at which point it'll feel like a gratuitously different SVN. However, as you find and make use of the other possibilities available to you, you'll have more success using Git.

Some of the first things you'll want to look at: doing many small commits, using many lightweight branches, and using commit --amend or rebase -i on local changes to fiddle with them before pushing them. Think of each branch as the result of your work, despite it containing many commits; you can edit the branch as a whole until you get it right, and then push it, much like you'd edit the SVN working copy until ready to run "svn commit". You get to have more structure in your working copy, and keep that structure when you push to the public repository.

One big recommendation, though: learning Git works a lot like learning the UNIX command line. You can learn a pile of individual tools, but it also helps to know the philosophy of how they fit together, so you can more easily string together impressive ad-hoc solutions when you need to. I'd suggest reading more about Git's repository structure, and thinking about it more as a DAG, and how the commands fit in that model.

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

#40

Post by JoshTriplett » Sat, Dec 03, 2011, 1:02 AM UTC

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.

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