BitBucket (http://bitbucket.org) went free for private repositories a while back and recently added git support. That might be a better alternative today.
I'm not sure why he/she didn't just link straight to that page. I also have to vouch for bitbucket's awesomeness though. Their tools might not be quite as fancy as the competitors, but they're slowly improving.
If you're using the free version of Fogbuzz anyway, you may as well use Kiln instead of Assembla. Hg is just as good as git.
I'd go out on a limb and suggest that if you are just working by yourself in pre-release development, don't even bother with a source code control. Use dropbox instead. It's simpler and faster until you get something up and running.
Once you actually need version control (as opposed to glorified backup) then you can switch for little to no cost.
I did this once on a personal project I was experimenting with. Then I started working on a change that turned out to be a lot bigger than I thought it was, and it ended up breaking everything. Trying to get it back to where it even worked again turned out to be so much effort that it totally killed any momentum I had.
So now I do everything in version control. Even minor little things I'm just playing around with. And I still use Dropbox as an extra failsafe against something happening to my version control repository.
But what is programming if not changes? :) You start with a skeleton (be it a bare bones Sinatra server, or a .c file with only main() and a couple of functions), commit it, then change it.
I'm not one of the downvoters, but how on earth is doing "your-scm-here commit" and typing up a description when you complete a task complex or slow? If that's even in the top 75% of the complexity in your app, you've got it so easy that it really doesn't matter what you do because you could just rewrite the whole thing in like five minutes.
On the other hand, the ability to try things and easily revert back to a known state is lost with the drag-and-drop versioning.
It's not, except that you need to do it. Most people don't do it every time they save.
I figured I'd get hammered for that suggestion, but the whole idea of version control is centred on the following two benefits:
1. Backup of files (every saved version)
2. Merging/branching/comparing etc. of various versions.
For a single developer with a pre-MVP development, point two is really irrelevant. (I'm sure there are cases where it wouldn't be, but I'm generalizing). I would argue that point one is better served by Dropbox (or something similar) than a full fledged VCS, simply because you're saving code and running/testing much more quickly than you are committing in these early stages.
Once you get to a certain point, by all means a proper VCS is the way to go.
Trying to save time by using Dropbox instead of a real VCS is being penny wise and pound foolish.
VCS systems like hg and git are incredibly simple to use for any professional that already works with them. You only need to run one command to create a repository and one command to create a new branch. It isn't necessary to commit your changes after every save. Even a few commits per day can provide a lot of benefit.
If I'm working on a new feature I'd much rather use git to revert false starts rather than hunting through dropbox to revert my changes.
I don't know what sort of diff tools dropbox has, but it is super easy to run git's difftool and see a complete changset between different checkins.
That being said, Dropbox is nice to give you offsite backups for almost zero effort.
I wouldn't even think of version-control as backup. Having your project backed up on a server is a nice to have thing of version control, but you should not use it like it was your backup system. If you are doing version control, you should commit semantically, not just cramming every files. even if you are a single developer, point number two is still relevant. Branches are very helpful when you want to work on new features without mixing up development. Its priceless to branch off and start working on new features without messing up your already working branch. You could technically introduce version control to your project once you are at that certain point, but why not do it before you start writing the first lines of code? Just my two cents.
"2. Merging/branching/comparing etc. of various versions.
For a single developer with a pre-MVP development, point two is really irrelevant. (I'm sure there are cases where it wouldn't be, but I'm generalizing)"
For me, most of the the strength of my chosen revision management toolkit comes down to its simple-to-invoke branch/merge alone. The ability to start a new branch for every idea and change request means I can manage and roll out changes far more effectively than with plain old versioning and backup.
You need to have a product to branch from in order to make branching practical.
Once you have that product, sure. If you're "branching ideas and changes" before you even have an MVP, you're doing it wrong. (In the sense that you should probably be focusing on getting that MVP out the door)
I'm not sure how you propose that we get an MVP out the door when you just described the entire process of writing software as "doing it wrong." How do you propose to ship a product without implementing any ideas or changing any code?
The point is that you can work fearlessly, confident in your ability to roll back if it turns out you've gone down a garden path. Even if you the probability of doing so is low, the cost of running version control is so low that it's really a no-brainer.
>How do you propose to ship a product without implementing any ideas or changing any code?
Well, that's an absurd oversimplification of my point, but it's really irrelevant; the entire topic isn't really worth the effort of the conversation. It was just a suggestion.
If you can't sleep at night without version control, then clearly, implement from day 1.
Version control works really well once you have something (anything) that is actually worth rolling back to. For me, this moment is a version that is "usable". That's when I create my first repository and commit. Prior to that, it just doesn't really make much sense to me.
I've seen so many instances where the problem was more "Shit I forgot to commit that" in early stage development that something like Dropbox can be so beneficial that it pretty much replaces any benefit at this particular point. If you commit on every save, then I suppose you wouldn't have this issue, really.
I have to echo the pro-VCS crowd. I've had so many times, even in tiny projects, where I've broken something in a really difficult to reverse way (or maybe I'm not sure how exactly I broke it, but it used to work, damn it!), and being able to simply revert with a "git reset --hard HEAD" is amazingly helpful.
I'm unfamiliar with hg, but git is incredibly easy to use. I alias common commands to shortcuts, so git commit is gc, git push is gpsh, git status is gs (I'll never run GhostScript from the command line), etc.
Any time I start a new project, even if it's just an experiment with a new library that will never see daylight, the first command I type after mkdir is git init.
Seriously, don't do any coding without version control. Once you've tried git, you won't want to (Mercurial is probably similar).
The reason is probably because you make it sound like setting up a VCS is such a big deal. Hg or git require literally running a single command.
It also seems like you think the concept of branching in hg or git has a lot of overhead too. Again, it is literally one command to create a new branch and one command to merge or revert that branch when you are done. I don't understand why you think one needs a working MVP in order to use branches.
Even when I'm by myself, I still need version control. It's nice to know that I can easily go back to any version I've checked into the system.
I use visual SVN for windows+tortoise SVN. I also can ssh into my box and check source files in from anywhere. If I had more than one person working on my source, I would start using Git.
It's better to use the right tool rather than the free one. I'm sure these products being recommended are great. I don't use any of them.
At work we use Pivotal Tracker, Github, 37 signals suite and others. They all cost money, and they all add value beyond their cost relative to free options. I would strongly advise against using "free" as your price point. It'll cost you.
On one hand it's true - you get what you pay for. On the other hand (and in my case) if you're a one-man startup and you're broke (or deeply in debt), you don't have money to spend on frivolous things like a web server, and free resources like this mean the difference between launching and not launching. I use everything I mentioned in my post... the only thing I'm paying for right now is a server ($60 for 6 months), a domain name and SSL Cert. The domain name? 1.99 with 10% off coupon and the cert was $10.
I'm not saying this is the best or the right way to do things, but for me it mean the difference between sitting on my butt, and launching.
Yes... The whole site is HTTPS but the disqus comments are served by HTTP. I need to make the blog section be served non HTTPS - this is #1 on my list of things to fix.
my co-founder were coding at the local library one day with vim full screen, and attracted the attention of the library security guards to come question him if he is "hacking" the library.
BitBucket (http://bitbucket.org) went free for private repositories a while back and recently added git support. That might be a better alternative today.