|more useful options|
How to best control non-working code with source control?by radiantmatrix (Parson)
|on Apr 11, 2008 at 17:42 UTC||Need Help??|
radiantmatrix has asked for the
wisdom of the Perl Monks concerning the following question:
I know this is slightly off-topic for PerlMonks, as it's more a general programming-process question and not in any way Perl-specific. However, I also think it's the best place for me to get a considered answer; and that the answer might be beneficial to PerlMonks novices as well.
I've long used source control -- mostly CVS -- for the obvious benefits. The most common benefit I get is the ability to solve those "damn, it was working yesterday, what changed?" moments.
My organization has a very good policy that you can't break the build -- that is, you only check in changes that have passed the current test suite. This is a good and useful policy for a myriad of reasons.
However, when I'm working on new features or particularly nasty bugs, I quickly found that I wanted to save particular points of my work -- perhaps when I got something promising working, or right before trying something experimental. Keeping track of commented-out code became unwieldy rather quickly as well.
So I developed the following approach -- but, I feel like I'm missing some obvious or easier solution to the problem. I'm curious about how other Monks might solve the same challenges.
Currently, our org has a CVS repository server called 'repoman'. I've set up my own server for development purposes ('devon'). When I work on a change, I:
I keep thinking there has to be a better solution to this that I'm just missing. What is it?