... say I check out some code, do a little dev or refactoring or whatever .. do I only check it back in when I'm completely happy? ... what if I change my mind about stuff while i'm coding? can I go back to a previous local version? is there a history of my local development?
Is version control about deployment history or development history?
Depends on you, on your team and on your tools. For example with a centralized version control system, you should not commit "broken" or "incomplete" stuff, whereas with a distributed one you can, and you will get advantages if you do. See here for more detailed (and interesting) examples: http://bazaar-vcs.org/Workflows
Short answer. It's both.
You need to be able to roll back to earlier versions for lots of reasons.
That depends how your Version Control system is used...
In my experience, most companies use it for deployment history in most senses. That is, only working code should be put in. If you check something out and then are in the process of adding a block of code that doesn't yet work - then checking it back in means that there's the possibility of someone else checking out a broken product.
I have come across situations where companies use it such that you check your code out each morning and whatever state you're in at the end of the day you check it back in. That way if someone else wants to add something they can, regardless of what state it's currently in... and while I can see some sense in the logic, that just doesn't work for me.
I think the correct answer is probably "it depends" :)
If you're using version control in a production environment, then it's about deployment history. If you're using it in a development it's about development history. If you're using the same version control system in both places (not uncommon), then it will probably vary by branch. For instance, you'd have your trunk and feature branches that are about development, then you would branch those into release branches which would be put onto production systems. The history of the release branches show the deployment history.
Some version control systems, such as git and mercurial, and I think SVK (a weird modified SVN) allow you to have local repositories that you can get previous local versions from. AFAIK, none of these will allow you to roll back if you didn't at least commit your change to your local repo. Eclipse also allows you to roll back to previous versions independently of your version control system.
... say I check out some code, do a little dev or refactoring or whatever .. do I only check it back in when I'm completely happy?
This is a matter of personal preference. Sure you can check in code that does not compile or where the feature you were adding is not complete. But it might be a pain to anyone else accessing your repository (if there is anyone) to check out files that do not work. I think the answer to this largely depends on the team size of your project and the team's personality.
is there a history of my local development?
Depends on the specific source control system you use. Git allows you to track local changes.
Is version control about deployment history or development history?
Development history, although I don't see what is stopping you from checking deployable files and configuration files into the repository with every release (however there are probably better systems for tracking this sort of thing).
In terms of checking back in, when you commit depends on your team's policy. Some teams use continuous integration tools to ensure that the current version of the code compiles and passes tests, meaning that you shouldn't usually commit broken code. Working in a branch may mitigate the risk of lost work in this situation.
For local history, you don't get this for free with version control, although some IDEs maintain their own local histories.
er, both...
You should be checking your work in any time it's stable - this will happen many many many times in development.
All source repositories have a version of labelling - you use this to mark release versions which are what ultimately is deployed.
So development mostly, but intrinsically releases as well.
Both, but primarily development history. The trunk doesn't need to be in a deployable state all the time--that'd be crazy.
Instead, you commit commit commit until you are ready to deploy. Then, you tag/label/branch your repository to indicate what code was deployed.
Jeff thinks you should Check In Early, Check In Often. I then to subscribe to the same kind of idea. Though, the way I do it is to use my trunk as my main respository that is "production" safe, while my branches are where I do all my development on. This way I can check in all my changes whenever I like without worrying about it going to production. When I'm finished with that particular enhancement, I merge from that branch to the trunk.
"Is version control about deployment history or development history?"
Both.
Revisions/file versions for developers and branches/tags/labels for deployment.
Much of it depends on the policies of your organization.
As for local working copies and revisions - if you have a VCS that allows either private work areas/branches and then promotion or a distributed system it really doesn't matter if you check in bad code and you can use the VCS for private stuff all you want.
For a centralized system you probably don't want to check in untested/uncompilable code...
again, this is dependent on your organization.
Version control is about safety and concurrent modification of stored information. Even with version control software you still need to define what is version and what deployment unit is. Without it version control offers only basic rollback mechanism and lots of options of low interest and subtle meaning.
It is definitely a personal choice as to when you check-in and what you check-in. Some things that can help determine the best choice would be whether you use a central or distributed version control system as well as if there is a team or an individual working on the code.
With distributed systems then whatever you check-in is local to you and only what you choose to push to others is what they see so if you have a broken tree because you check-in frequently it does not matter whereas with a central repository should you be checking into trunk then it is generally a good idea to have only working code checked in. How would you feel should you do an update to your tree and someone else on your team broke the code and then your copy will no longer compile. A simple way to work around this problem in a central repository setup would be to branch the trunk code, make your changes committing frequently and then when you are happy that it is working correctly you can then merge your branch back into trunk. This way you do not stop trunk from always being in a runnable state which is a useful state to keep it in. This becomes even more important as you add people to your team.
With regards to going back to previous versions, this is not a problem if it has been checked into the repository. You can go back as many versions as you like by looking at the commit log and then using the relevant command to go back to a specific revision.
Interesingly enough, no one's mentioned using branching yet.
Branches are a great way to keep the trunk healthy while continuously checking in whatever you're doing, broken or not. Think of it as forking off a new timeline for the code; the primary timeline (the trunk) chugs along and is always working; the branches can be any state at all without impacting the trunk.
This allows you to commit early and often without having to worry whether you've messed up someone else, and guarantees you never have a I've-gone-too-far-and-can't-reverse-this moment when developing something new, or an oh-Lord-I've-lost-a-week if your local disk should die. (It goes without saying that your repository should live somewhere that is frequently backed up!)
Once your code is working, you can merge the branch back to the trunk, and the trunk now gets your new code; new branches from the trunk now have all of the working-up-to-now code.
This is the huge appeal of git to many: it's really easy to branch and merge, making it very easy to just toss off a new branch, or even branches of branches, whenever they're needed. Even CVS can do branching and merging, though it is considerably more cumbersome.
The margin between these two is very small. However, if the version control is used correcty it's about source control, meaning the development control/history. If used well you check out often and get a nice version history, which can alsbo be used to track when you did what, for time reporting and do fallbacks when errors occure.
Short answer is, both when used correctly :)