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