3

At my company, we are currently using Subversion. Our project development process consists of a "live" branch of code (this is what is on our live web servers), a general dev branch for smaller projects, and then each larger project has its own separate branch. We usually have at least 2 larger project in development at any given time. Merging those back into the live branch can be a pain, but what's more of a pain is when large project 1 goes live, then large project 2 is going live a little later, and that merge process is just... messy.

What I've been doing in SVN is to have a daily merge from live (so any bug fixes etc. that happen) to the development branches. But the larger project merge process is still messy, and I'm wondering if it will be cleaner with Git. As one example of something "bad" that's happened with SVN, we will have a small feature on dev, merge that to live, then when performing the live backmerge, SVN tries to merge that feature back into dev again (causing a conflict), unless we manually deselect that commit in the merge. From my understanding, Git is "smart" enough to know that commit originated in dev, so it wouldn't try to merge it back in... but my understanding could be wrong. I also hear that Git is better at automatically handling complex merges like we're trying to do.

So, first question would be: is Git notably better than SVN for what we're doing, or would we still likely run into the same issues and just-as-hairy merges?

Second question: Are there other integration methodologies that may work better for our scenario? In particular, I was reading an article about promiscuous integration that seemed good, though that also seems like it would get exponentially harder the more projects are going simultaneously. But then again, I don't expect us to ever have more than three big projects at the same time, and usually just two. Continuous integration isn't an option for many of our projects, because they tend to be all-or-nothing projects, or ones that would be jarring to users if pushed in parts (e.g. our recent redesign of our checkout process). This article also seemed a good methodology for our situation.

Mike Todd
  • 7,227
  • 2
  • 15
  • 11
  • 3
    Check [this Q&A](http://stackoverflow.com/a/10340877/236871), basically Git is better than SVN at merging because how they store the information and how the do the merge process. Git stores full snapshots, SVN stores deltas/diffs. At merge Git does 3-way merges, SVN reapply patches/diffs. – KurzedMetal Mar 01 '13 at 16:34
  • There's a free webinar about advanced branching and merging in a few weeks. http://go.wandisco.com/advanced-branching-merging.html – vinnyjames Mar 01 '13 at 23:12
  • As a note, we have moved to Git, and have found it much better -- there have been almost no conflicts during merges. The main pain point was when we merged some code to master and found a serious bug that had escaped QA, after further merges/commits had occurred on master. Backing that out was a lot more difficult in Git than in SVN. But overall, Git works much better for us than SVN. – Mike Todd Nov 20 '13 at 16:38

5 Answers5

5

We let people use whatever tool they feel most comfortable with. git-svn offers a git-lite experience for folks that are more comfortable with or want to learn git for professional development. There's a project out there called SubGit which will let you have SVN and Git for whoever wants to use either.

Generally speaking, folks that branch/merge a lot according to the feature branch development style tend to prefer git. It's also a lot less overhead for several team members to collaborate independently of the rest of the group.

Peter Bratton
  • 6,302
  • 6
  • 39
  • 61
3

Try git, you will not go back.

I would say stick with Svn ONLY if you don't do any merging (i.e. work on trunk in a small team). All other cases, including yours for sure - git will make your life easier.

Git is way better than SVN when it comes to branching, merging and resolving conflicts. Think about SVN "one checkout dir per branch" scenario for instance. Moreover, git is so much better with merging/branching, that some people are using git-svn to merge SVN branches. Imagine that the other way round...

Also, This answer is pretty good at explaining Git vs SVN.

Community
  • 1
  • 1
Adam Adamaszek
  • 3,914
  • 1
  • 19
  • 24
3

"Git has a learning curve" -- true. On the other hand, after the learning curve, the developers start understanding the concepts of source control systems much better. They get more organized and do things in a much more practical manner.

Yes, if you need to migrate a repository from Subversion to Git, you branch layout will be different (among other things). But the history will all be there.

One cause for the usually slower learning curve is that quite a few of the commands have different names and it takes some time to wrap your head around it.

Git is not good with repositories of large sizes (in terms of data). However, you can always modularize your system and extract bits of it. The benefit of this concept is usually not understood well enough (at companies and corporations with tons of crappy legacy designs) in order to be appreciated well enough. If you have a huge repository (such as what is normally the case under SVN/Perforce and the likes), you have all the code for all your projects in one place. However, Git allows you to keep the entire history of your project in your local clone. Imagine if you've properly modularized everything -- you can have complete histories of your modules checked out as single entities. Git follows the principle that you should have a repository per project (at least that's how most people have adopted it). Maintaining a small tree of code is always simpler, quicker and tidier. Branching, merging, re-writing history, extracting directories with their history into separate new repositories... all of this is so, sooo easy.

Git is something you should definitely try. Even if you're afraid of it. Read the ProGit book. It's good and has excellent examples and explanations. You will quickly find the limitations of Subversion. I used to work with CVS from it's early days, then migrated to Subversion and administered it for many years. When I started dealing with git (once I've read the book), I really realized how smart this version control is.

Really, if you try it and dedicate some time to it, there will be no turning back for you.

If you would like to start off and learn it quickly, I would recommend setting up a project in GitHub and playing around with it for a bit. They have excellent explanations to get you quickstarted.

carlspring
  • 31,231
  • 29
  • 115
  • 197
0

I think if you are used to SVN keep using it . Git is very good but you still have a learning curve and it will be disruptive to start using it . Svn works fine so maybe you can improve the structure of "branches" and "projects" on your company . It sounds like you have a structural problem which is not related with the tool . Anyway it's just my humble opinion. I hope it helps .

hopper
  • 4,230
  • 8
  • 36
  • 49
0

the larger project merge process is still messy, and I'm wondering if it will be cleaner with Git.

No. Your problems are not (mostly, as I can understand process) in the used tools, they are more heavy questions of organization and management of the development process. Changing tools doesn't destroy bad habits.

You main problem isn't "bad merge" (BTW, I never seen described "backmerge bizarre", while use sync-merge to branches regurarly - and merge these branches to trunk later), but "chaos in minds". Git-merge is (in common) more robust, but you'll step on the other rakes, which are much more in Git

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110