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