How Do You Control Your Source Code?

[eluser]BrianDHall[/eluser]
I've never used source code version control of any kind, and I hear so much about its importance that I'm thinking I'm missing out on something (like what a big difference having a debugger is). I've heard much of CVS and SVN, and now I see git is considered a big deal, etc etc.

What I've had happen is I make some change, get a week down the road and then go "oh, I wish I hadn't deleted that piece of code..." or something gets terribly screwed up and I need to go back to a functional version and start anew.

The way I handle this now is I zip up my CI application and gmail it to myself every day or few days or so.

Old fashioned, huh? Thing is, I don't like messing around with stuff that doesn't make a Big Difference. If it's not really vastly superior to my existing 'system', or it is only important in a large team environment, or if its needed for 'builds' (which I don't see the need for in my projects, there is just the live commercial version and the development version).

I program on Windows and deploy onto Linux, so anything I choose will need to fit this. Ideally I could install it onto my linux server and then use a client on windows, but even better I'd like to be able to have a server on windows itself to learn it better - because I don't really like installing anything on my server, as its locked-down tight and PCI compliant and it's a pain in the ass to manage as I'm the admin too

So, I'm I missing out on something that would be worthwhile, or have I just not used it because I really don't need any fancy or automated source control tools?

I only relatively recently started using an IDE (PHPed), ORM (DataMapper), and of course the CodeIgniter framework after many years of using pure PHP and Editplus - because they worked just fine for what I wanted to do and I didn't have to spend time learning tools when I could have been programming. So that's pretty much my philosophy on dev tools - I don't like getting programs or tools 'just because', or that take more time than they are really worth in the short-term.

Thanks for everyone's experiences, opinions, and suggestions!

[eluser]jedd[/eluser]
Hi Brian,

I've used subversion a fair bit, and am a recent convert / advocate to git. I know where you're coming from with not wanting overhead into your work flow, but I reckon this would probably be worth it. Check out the git tutorials - they're pretty straightforward mostly - and create your own repository and have a play with it.

You still need to do regular backups - git doesn't replace that - but for 'snapshot in time' stuff, working with copies of things you've emailed to yourself (or in my case, tarball'd up into a directory somewhere) is just so painful that it alone makes git worth the price of admission.

Rather than think in terms of client and server, you might want to think of your linux and windows boxes as being peers - you still have a permission system wrapped around the stuff, but you can push your current 'master' branch to your production box with a single command. It means you can easily swap between master and various test & experimental branches on your local computer, developing each of them separately (in effect), and then merging them once you're happy with where that thread got to.

Look at the two links I posted in [url="http://ellislab.com/forums/viewthread/124861/P30/#633089"]that other thread[/url] a minute ago.

Also check out Phil's [url="http://github.com/philsturgeon/pyrocms/tree/master"]pyro CMS tree at github[/url]. I draw your attention to the graphic you see when you hit the Network menu item there - it'll give you a phil-centric view of changes to the project's files. You can click on the other user's mentioned and get them-centric views. It's one of the best ways of understanding the distributed nature of git (as compared to the server-centric nature of svn, say).

Better yet, pull that down using git-clone to a 'foo' directory on your box, and crank up gitk (the graphical front end - not sure what the MS-Windows equivalent is - might be called the same thing) - and you'll get a comparable understanding I reckon.


So, yeah, to answer your question - I think you're missing out on something really good.

[eluser]n0xie[/eluser]
I would advice to start of with subversion. It's what the whole world uses (yes some projects are migrating to git, but subversion is still leading) and being able to understand revision control is much 'easier' when you have a client<->server setup. Git has a steep learning curve as is. It's difficult to grasp for most people who are used to version control at first, just because it uses a basic different set of philosophies than 'regular' revision control systems.

So get to know subversion and the 'lingo' attached to revision control. Learn what 'commit', 'update', 'checkout' and 'export' all do. Once you have some understanding of why every developer needs revision control and what the advantages are, you can take a look at git and see why it's 'better'.

I can't stress this enough. Every developer needs revision control. I can give you a big list why, but it's much easier to just assume the whole software industry knows this to be true and just go with that.

There are a ton of tutorials how to setup a SVN server on both Windows as well as Linux, so I'll just leave you with the online svn book: http://svnbook.red-bean.com/en/1.1/ch01s07.html

[eluser]jedd[/eluser]
Hi n0xie,

You appear to be contradicting yourself a bit here. You assert that git is difficult to grasp for most people who are used to other version control systems, and at the same time you are suggesting that Brian learns a different version control system before trying to use git. Sounds like you're trying to make it extra hard for the poor chap!

I disagree about the steep learning curve with git. The two links I posted in that other thread would get you running - and cover pretty much all of Brian's requirements alluded to above - in under an hour.

The 'whole world uses it so it must be good' theory isn't up to your usually high standards, either. If that was a sound principle, we'd all be lining up with our thousand US$ to buy our own copies of Fista + Office. And we'd all be using Cake / Zend. (Though in your defence, we'd be spending time learning those so that it'd be more confusing for us when we came over to CI.

Version control systems are something that, like a handful of other typically large / collaborative software types, are very hard to change mid-project. The linux kernel did it - mostly out of sheer bloody mindedness and a complete lack of viable alternatives I concede - but nonetheless it's a massive undertaking to swap over to a different vcs. Consequently most of the Whole World is using svn purely because svn has been around longer than their project, and at the time they started svn wasn't as sucky as cvs. Not a hugely compelling reason to jump on the subversion bandwagon for any new project, IMO.

[eluser]n0xie[/eluser]
I agree to some extend but most likely I look at it from a different point of view.

Let me explain in a more real world example: SVN is used by the majority of companies. For example CodeIgniter uses SVN as well. To know how to use SVN is a requirement, or rather, a necessity if you ever embark on co-operation with other companies. That they use it purely because it has been around longer or that there are better products out there does not change any of this. The fact is that it IS the industry standard. I explicitly say companies, since git is mostly used for open-source projects. Being in 'the business' for a while I know how slow companies are to adept to new superior technology (*cough* linux *cough*). So even if I were to suggest using git to work with other companies, they would probably just say no, since SVN works for them, has worked for them, and they hate change.

So in this case, 'the world uses it' is actually a compelling reason. The same way 'Office-compatible' is a compelling reason for business people to still buy a new version of Office every time it comes out. I personally hate it when people send me their requirements in the usual proprietary format but that doesn't change the fact that if my business wants to get work, I have to comply with what 'the world' uses. And in this case the 'world' uses MS Office and the world uses SVN.

Now I don't know what kind of projects BrianDHall works on. If it is his lively hood then I would strongly urge him to at least learn the basics of SVN. If it is just (personal) hobby projects, git is fine.

So where I come from, knowing SVN is an absolute must. We both reason from a different perspective I guess. I work a lot with all sorts of companies. They all have their revision control systems, but the one true revision control system is and has always been SVN when companies work together.

Another reason I would go the SVN->git route is because git is compatible with SVN, but not the other way around. So once you have your project in SVN and you have 'mastered' git, you can rebase your repository. The other way around is as far as I know not possible.

The last note I want to add is about the steep learning curve. I know this is a bit of a subjective argument, but the truth is that git works differently than 'normal' revision control systems. Maybe learning the normal way first and then 'unlearning' it to use git is a bit counter intuitive but at least it will instantly show you why git is deemed 'superior' and why it has different basic design principles.

At least we both agree that revision control is something that is essential for developers

tl;dr:
Learn SVN if you have to work with other companies in the future.
Learn git if you do your own work, programming is a hobby, or don't care that other companies use SVN.

[eluser]jedd[/eluser]
Sure, I absolutely agree that if you're going to work for a shop that uses a certain type of software, then you'd learn that software. So if you were going to work for Google, you'd learn Perforce. If you were heading into a Microsoft-based shop you'd shoot yourself in preference to having to deal with SourceSafe or TFS. But yes, I understand the implication - because lots of people use subversion, there's a commercial imperative to understand it. Happily nothing in the original post suggests the existence such an imperative.

I think your learning curve expectations might be based on experiences with earlier versions of git. By all accounts it used to be pretty horrendous. I gather it's now considered to be comparable, in terms of command complexity and (ease of) feature accessibility.

For a two-machine setup, with little chance of collaboration with other humans, where high performance and a cheap branching mechanism are the two biggest selling points, it'd be a tough call to pick a server-centric, slower-performance system.

Curiously, I recently found the site [url="http://whygitisbetterthanx.com"]Why git is Better than X?[/url] which lists [url="www.github.com"]github[/url] as being one of the biggest selling points for git. I hadn't really thought about that before, but github is where I first got the warm and fuzzies about git. Maybe there is a subversionhub out there (googling for it takes me to a London S&M club .. which happily answers the question 'What will I do tonight?')

[eluser]n0xie[/eluser]
Github is pretty awesome, I agree.

But SVN has perks too. For one, integration with other software is far more established. TRAC being the most obvious but there are others like Bugzilla. Also, there are better (read: user friendly) tools available especially under Windows (TortoiseSVN is a bliss for any windows user. I am quite envious coming from Linux).

Also don't forget that git is very UNIX centric, meaning if you use git on windows you lose a lot of it's key features, speed being one of them.

Btw I do think git is great, in case you couldn't tell from my argument, I just think you first need to learn to walk, before you run

edit: Apparently there is a TortoiseGit http://code.google.com/p/tortoisegit/

[eluser]jedd[/eluser]
Wow .. I remember playing with tortoisesvn years ago. Ah, what memories.

I take the point about MS-Windows being a bit of a challenge, but again, this has apparently improved leaps and bounds in the past year or so. Still, I do tend to forget that some people around here still develop on a Microsoft platform.

I found [url="http://nathanj.github.com/gitguide/tour.html"]this pictorial guide to running git on MS-Windows[/url] which might be of interest to Brian.

Oh, I'm running the git-plugin on my trac system at the moment, though I've found two small problems with it (can't cope with spaces in filenames, and trac-links to the git repo aren't parsed properly). For tools, I thought git-gui and gitk were pretty reasonable? I haven't really played with the GUI tools for either git or svn much though - too much of a CLI bias.

[eluser]BrianDHall[/eluser]
For my personal situation, I'm now a 'professional' web developer - it's my job. I'm The web guy for my company, and no form of formal process existed in the past. I have an ASP property management site I'm responsible for (boo, hiss - on the upside I can now say I have experience with .NET ), a coupon website, now a rental website, and probably a web-based software application next.

Basically, I can setup whatever I want. I have my home PC and a work PC (32-bit Windows XP at home, 64-bit Vista...ugh (I didn't pick it)...at work), and we have a dedicated server that runs linux, which I'm also the sole admin for. On a tangent, "unmanaged hosting" is a nice way of saying "we don't know what we are doing and are not going to be of any help in the future, so don't bother asking us for anything, even if we screwed it up in the first place".

I've always done my own projects, and haven't had a coding team member. I've always been the only person in a job that knew how to code.

I was out of programming/development for like 2-5 years - CVS was the de facto standard back then, almost no one used an IDE for PHP (which was only version 4, with 5 being just a wet dream), frameworks (and rails) didn't exist and I heard of some weird little language called ruby that was cute but worthless, and unit testing was for software developers. Oh, and debugging was the judicious use of var_dump. And if you wanted help you posted on the PHP mailing list or visited PHPBuilder. Of course MySQL was the state of the art, and only the koolest kids had functions that let them minimize use of SQL writing by hand.

So, I'm trying to catch up with the times

---------

With that said, I am trying to decide if I should use any control software for my current projects. I'm only one person and no one I know personally or work with knows programming (well my boss knew fortran back in the day...), so I have to judge it purely on a "Will it help me Now" basis.

I know that knowing CVS, SVN, and git would all be of use to me jobwise, which will be an issue because you always have to keep your options open - but I want to learn Adobe Air/Flex, improve my javascript skills, understand AJAX, build next-generation rich web applications, and on and on - I have lots I want to learn, I just have to decide what to learn first.

And I have to juggle this all with doing actual work and getting things done, so I can't be all bait cutting and no fishing

So what do you think, with either SVN or git, would it be of use to me as a single professional programmer, or is its value really only shown in a multi-user environment?

-Brian

[eluser]jedd[/eluser]
[quote author="BrianDHall" date="1252108635"]
So what do you think, with either SVN or git, would it be of use to me as a single professional programmer, or is its value really only shown in a multi-user environment?
[/quote]

I think the one thing n0xie and I definitely agreed on is the fact that you will benefit from having .. something.

The current way you're working - tarballing, noting dates on the file, perhaps a brief explanation of what changed in that week, and the pain of pulling things apart in order to work out which of those archives contains the 'little change' that you need to find and revert again, but wasn't important enough to make into the archive's filename when you saved it ...

All that stuff stops being a hassle once you start using a cvs. Did you read the [url="http://www.spheredev.org/wiki/Git_for_the_lazy"]git for the lazy person[/url] page? It'll give you an overview of what's involved (SVN will work similarly to this) as it's all pretty basic stuff that you'll be doing. The complex things are merging multiple branches from multiple developers .. which, as you observe, isn't going to happen around your way.

I kicked off a new branch this afternoon, for example, where I'm finally going to go through and fix up the security on my sql calls - there's a few places I've been a bit slack. So I did this:

git branch safe_sql
git checkout safe_sql

Nothing changed in my application directory when I did this, mind. It just means that I can easily revert to my previous 'master' branch (git branch master) and that'll hide all the changes I've been doing to my SQL calls. This borders on pointless, as I tend to work on one thing at a time, but it's very handy when I look back at my changelog. If you look at the [url="http://github.com/cbosuna/codeigniter/commits/master"]github page for CodeIgniter[/url] you can see the comments, and by clicking on the commit hash on the right of each comment, you can see what was actually changed. You'll learn to embrace the 'commit often, commit small' approach no matter which cvs you choose.