what if you have more than 2 versions, or if your #ifdef's get nested and more hairy? slippery slope to preprocessor hell :)
with git, there's a nice 'bisect' feature that lets you quickly jump back-and-forth between different versions of your code (in a binary-search-like way), so that you can debug performance issues like the one you're using #ifdefs to manually do. just check in a bunch of versions of your code and use 'git bisect' to jump between them and test each out for performance (or correctness)
Realistically, you wouldn't normally have more than two versions: one "solid" and one "experimental". But if you do, there's #elif. I repeat: I see conditional compilation as a temporary thing. My code does not end up littered with them.
> with git, there's a nice 'bisect'
How does "bisect" know where the boundaries are? What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? What happens to time stamps when you switch between the versions? Versions cached in the IDE? Directories? (You may be surprised that Git leaves them around from previous versions)
It's all doable, but not very intuitive. Why bring complexity where there is enough of it already?
If you're say, changing an API, and then you've modified all the code that uses that API that's a large number of files with defines in them, right?
Your work flow is limited to the method you've chosen not the other way around. To say it works for you sort of misses the point. Version control can free you to work in ways you can't yet imagine.
> How does "bisect" know where the boundaries are?
Clever algorithms.
> What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? '
The file gets flagged in your editor as having a conflict. Inside the file, any code parts that cannot be merged are included the file (both versions) and you pick which one you want (or edit the changes together manually). It's actually very easy, very intuitive, and works with your editor. In most cases, you won't have conflicts.
> Versions cached in the IDE? Directories?
I've never had a problem with versions cached in the IDE -- probably because almost everyone uses version control it's not something that usually goes wrong. With IDE integration, it's even better. Directories are handled pretty sanely in Subversion, at least.
You obviously take the snapshot before. No different from the more over-engineered approaches.
>> How does "bisect" know where the boundaries are?
> Clever algorithms.
Really?! You change two methods in a class, and "bisect" knows how to undo only one? No, you have to spoon-feed it, "staging" your changes (I did use GitX for a day). So it's not as simple as taking snapshots after all, is it?
Git bisect is a binary search. You tell it what the last known good revision is, and then it'll perform a binary search for you between that revision and the latest revision. In each step of the binary search Git will ask you whether the current revision is good or bad, and in about O(log N) steps you'll know which exact revision introduced the regression.
> (You may be surprised that Git leaves them around from previous versions)
Git leaves directories around only if they contain files that are not checked in version control.
with git, there's a nice 'bisect' feature that lets you quickly jump back-and-forth between different versions of your code (in a binary-search-like way), so that you can debug performance issues like the one you're using #ifdefs to manually do. just check in a bunch of versions of your code and use 'git bisect' to jump between them and test each out for performance (or correctness)