Source Code Control Question

[G+_Colin Nelson]

Source Code Control Question

 

Good Day to you all! I'm a Senior Dev at a medium sized company in the Energy industry, and I also happen to be our Subversion Administrator. We have been using Subversion for the past 15 or so years and its worked beautifully for us. Our company has a fair amount of repositories (~100)  and  about 250-300 users need access to the repositories (some technically inclined ,others not so much)

 

I am always open to new ideas, but I'm still on the fence about GitHub. I know that many Devs are using it, so I signed up for GitHub and downloaded the Windows Client. I made a few repositories, worked on them, branched, merged, purposefully put myself in conflict, just to try to get the feel for it.

 

I know they are only in version 2.6, but I felt very lacking in the code management. There appeared to be no conflict resolving tool other than "Go to the command line" and should a merge fail, there were no descriptive messages other than "Go to the command line"

 

Is this expected? I have no fear of the command line, but I feel I may have been spoiled by TortoiseSVN which has diff management, conflict resolution and decent merge error messaging in a Gui form, and I fear that my non-technical users will rise as one and slay me should they have to manage conflicts with the command line.

 

GitHub is CLEARLY doing something right. Developers love it.  Gina even said in TWiG after I/O that it was nice to see Google putting their code on GitHub because they were "going to where the developers are".  I just simply wasn't blown away by using it. I felt underwhelmed. Am I missing something?

 

What is it about GitHub that makes it your preferred choice in source code control?

[G+_Joe C. Hecht]

I might ask the opposite, as in "what is it about GitHub that does not make it your preferred choice for source code control"? Admittingly, I was also not blown away, but to be very fair, source control for me means zipping a bunch of files and stashing the zip file away, and at best, a merge involves perhaps 2 people. On the other hand, my projects can be fairly large (my current project is over 29,000 source files in a top down build, split up over 9 machines that actually do the builds), so source control might be a good thing. It's getting to be a lot more than I want to manage, and I sure have been putting some thought into adding some sort of source control.

 

You have asked a great question, and I am certainly interested in hearing from all sides. Thanks~!

 

TJoe

[G+_John Stoume]

I am also not very impressed with github, but I use it occasionally because that is where a very large number of the people and their code is. I prefer fossil-scm.org which has free hosting on chiselapp.com but I don't think you should switch from what you are already using unless there is a compelling reason. I think github has the crowd, but what is good for the crowd is not always what's best for you and yours.

[G+_Colin Nelson]

Joe Hecht, at the end of the day, the ONLY thing that makes GitHub not my preferred source code control is that I have a working system (Subversion), and if I were to push our corporation to migrate to GitHub, the command line-phobic users might revolt.

 

Our company is growing rapidly and I want to make sure that we can scale properly, and source code control is a big part of that, and if GitHub is the answer, then I want to jump on that sooner rather than later.

[G+_Colin Nelson]

I agree John Stoume, what works for one group is not always the solution you need. There is no way I'll push our company to another Source Code Control software unless I"m absolutely positive it is a significant net gain for the company, but I worry about "future proofing" our company.

 

If all the bright, young devs have been brought up on GitHub I want to make our workplace attractive and enticing to them from a hiring standpoint. That being said, I don't know of anyone who turned down a job because of source code control choice. 

[G+_Lee Crocker]

Firstly, let's separate Git itself from the Github site. Git is a command-line tool, no two ways about it. It's also a Linux-based tool. Sure, people have made GUI wrappers and Windows ports, but those are sometimes tracked-on and not very complete. If you want the full power of Git, you are expected to do so from the shell. If you can find (or write) a GUI wrapper to help you, that's cool, but that will likely be a local special-purpose thing.

 

The real question to ask is whether you need Git's fundamental difference: its distributed nature, a opposed to the centralized ?SVN. In a corporate top-down environment, maybe not. In a project like the Linux kernel with hundreds of developers with differing ideas, absolutely. Git (and Github) allow some truly magical interactions with your fellow developers: branch, merge, and fork at a whim. Keep multiple masters in different places. There's really nothing like it if you need it, by not everyone does.

[G+_Colin Nelson]

Lee Crocker thanks for your insight! You bring up a good point about Git's distributed nature. In my example where I made my own repository and started checking in code I was not leveraging that fundamental difference between Git and subversion, which probably contributed to my lack of enthusiasm. I'll have to think hard and ask the product teams more details on their roadmaps and see if any are wanting to go for a distributed approach before I make a decision.

 

Thinking about it some more, there is no reason why Git cannot behave exactly like subversion isn't there? You just don't clone it into new master repositories.

[G+_Joe C. Hecht]

Lee Crocker Great post Lee. Side Question: Am I wrong in recalling that someone created a project using GitHub source to create your own private cloud with a sync file capability? 

[G+_Mark Cahill]

Colin, I manage a development team at a large organisation. We don't use github but do use git which we host internally (github is just a hosting service that uses git - git is the version control system). We were fully on subversion until recently but transitioned across.

 

One of the big benefits I've seen, which might not be obvious, is that git is actually much better at managing conflicts than subversion was.

 

There are a number of GUI tools for managing git branches. I tend to use the command line and Atlassian Stash. But others in my team use Atlassian SourceTree, git extensions, gitgui and TortoiseGit.

 

It's probably best to learn about git from the horse's mouth:

Tech Talk: Linus Torvalds on git:

[G+_Colin Nelson]

Thanks for the comment and the link, Mark Cahill. I'll definitely watch that.

 

I focused on GitHub largely because it is popular, and offers a in-house hosting system as well. I used the standard Git gui and felt like I wouldn't be able to get buy-in from my users. I will for sure look into those other options. Thanks!