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.
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.
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.
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.
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)
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.
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.