I have to respectfully disagree here. Having super-lightweight branching and local commits has helped me greatly, even in the tumultuous early days of a new project. Basically, it gives me the freedom to create a branch, hack for a while, and then either pull the changes into the trunk or abandon them, while still keeping an easy "bookmark" in place (a.k.a. the branch itself) to go back and review later.

Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time).

Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.

> create a branch, hack for a while

$ cp -R project testbranch

> then either pull the changes into the trunk or abandon them

diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.

I'm not arguing with the value of a filesystem as a general-purpose organizational tool. However, it's a strictly weaker tool in terms of structure and semantics than a proper VCS. Also, not only does using a raw filesystem put the burden on you to remember the associations between branches and versions, it also gives you zero support for merging once those branches are made.

Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches.

Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.

FWIW, multiple backups and hardlinks are the basic foundation of git. Running 'git commit -a' a few times a day to check in all the changes isn't a big timesink; commit messages can take time or not depending on how detailed you care to be.

I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.

It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.