Poll: Version Control

For new projects I'm using git rather than subversion. I normally develop on my desktop system, but when I'm on the go I use my laptop. Subversion isn't useful for that kind of scenario if you don't have constant internet/network access. With git I can do commits, look at the history, etc. even when I'm on my laptop and offline. (you can keep copying the whole repository with svn but that pretty much defeats its purpose)

I'm pretty new to git though, and I haven't even touched the more advanced features.

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.

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.

All projects right now use Subversion except one new project at home that I decided to try Git out with.

All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers)

I like Git .. it's very fast and simple to use :)

I know from experience that git is superior, but I still use svn because it is the (modern) Lingua Franca of revision control. TortoiseSVN on Windows also gives it a definite advantage on that platform.