Thanks for this post, it's all too easy to forget all this in your daily routine.
If the OP reads this, if you work at a company where much of this isn't possible, why not move on?
While the participants are encouraged to use TDD, this is no strict rule. The goal is to write the best, cleanest code you possibly can.
What I've found the most value in, is that you get to pair with 6-7 different programmers you've probably never met before - and thus you get to learn how other people approach the problem, you'll learn how your skills compare to those of others and you'll also learn a lot of little things, e.g. IDE shortcuts you didn't know of.
And you usually get to program in a language you might not be familiar with.
I've already attended two code retreats and it was very, very well worth it!
To answer to the question in the title of this submission:
You should not. As soon as a feature has got released to all users of a software, you won't be able to disable it without some users becoming really dissatisfied.
The solution is not to release a new feature to all users.
Before even thinking about releasing a new feature, first ask yourself:
What is the goal of this new feature?
The answer to that question is your hypothesis, you need to try to answer by experimenting.
That is, perform an A/B-test:
Launch the feature to a subset of your users and check if it achieves its goal.
This goal must of course be measurable and ideally there are KPIs that you can use to check the success or failure of your experiment.
When the experiment is successful you deploy the feature for all users.
If the experiment fails, you remove it for the subset of users and the rest will never know about it.
This also helps the codebase to stay clean, features not making it into the product, is code not making it into your codebase, which means less code to maintain, less complexity.
Well, actually git-svn is really useful when you work in an environment where SVN is used as VCS.
I've been doing this for almost three years now and haven't had any major problems yet.
Except for:
Merging.
Since SVN 1.5 (or so) merging in SVN got less painful because from then on when merging, SVN tracks which revisions have already merged from one branch to the other.
AFAIK it does so by saving the merged revision ranges into the svn:externals as meta data which can then be used for the next merge operation to prevent changesets to be merged twice into the same branch.
However, when you merge with git-svn this information will not be recorded, so the next person merging with SVN will probably run into problems.
Solutions:
a. you don't merge with git-svn
b. anyone merging with SVN explicitly tells SVN which exact revisions to merge
You can still use local branches of course and as long as you only merge from one local branch to the other with Git, there won't be any problems.
At my work place we luckily pretty much only have trunk and very, very short-lived branches, so this isn't an issue for me.
A correction, while the fact that SVN creates a copy of the entire code, when you create a branch, it isn't as horrible as it sounds, from the SVN documentation:
"When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects."
On peepcode.com you can find several screencasts where you can watch experienced developers working on a mini-project while thinking out loud
The series is called "Play by play".
Here's the one with Zed Shaw:
http://peepcode.com/products/play-by-play-zed-shaw
I was about to suggest that book, too.
Also, check out this blog post:
http://agilitrix.com/2011/03/how-to-make-your-culture-work/
which outlines some of the ideas presented in the book "The Reengineering Alternative: A plan for making your current culture work" by William Schneider.
A friend of mine ran into the situation of having to implement the same business logic in both Javascript and Ruby.
He wondered how to get around this and his solution is IncludeJS which allows to write the business logic in Javascript and use this code in BOTH Javascript and Ruby.
He gave a talk about this during the Railsconf 2011, here's the URL where you can find the abstract and slides which provide some more details about this:
Nice!
By they way, the hints, tips, tricks and plugins in that article can be applied to using Vim with other languages as well.
Didn't know about Gundo or minibufexpl, for example.
I don't know if it's decent, I'm a Linux user but there's TortoiseGit:
http://code.google.com/p/tortoisegit/
Current version is 1.6.3.0, so looks like it's considered stable enough to be beyond the 0.x-stage... ;)
I agree that most of the slides would require further explanation but I still found a bunch of commands I've never heard of and actually could make use of, eg git bundle and git rerere.
Which issues did you have exactly?
I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid.
My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git like local branches etc. pp.
That's what I'd recommend to anyone making the switch, first try it out with git-svn, don't use every new feature at once.
DVCS is a completely different paradigm, it requires some time to wrap your head around. :)