How to best control non-working code with source control?

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:

cvs co code from repoman into the "official copy" directory.
cvs co the same project from devon into the "working copy" directory
rsync the official copy to the working copy, one-way (update the working copy), and excluding the CVS directories.
cvs commit the working copy to devon
Make some changes, but maybe still have some broken code
cvs commit to devon, goto 5 while code doesn't pass all tests.
Once code is working, rsync working copy back to "official copy"
cvs commit to repoman

I keep thinking there has to be a better solution to this that I'm just missing. What is it?

<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Comment on How to best control non-working code with source control? Select or Download Code

Replies are listed 'Best First'.
Re: How to best control non-working code with source control? by pc88mxer (Vicar) on Apr 11, 2008 at 17:50 UTC
Branching and merging is the way to go. If you have useful code (even experimental code) it should be in the repository. Unfortunately `CVS` doesn't support branching all that well. `SVN` (Subversion) I hear is better at it. I personally would look into `git`. It's even been used to perform merges for a `CVS` repository.	[reply] [d/l] [select]
Re: How to best control non-working code with source control? by kyle (Abbot) on Apr 11, 2008 at 18:02 UTC
I'll echo pc88mxer. The better way is with branching and merging. The workflow goes like this: Create a branch off of trunk/master/production. Within that branch, make changes. Do commits to the branch at appropriate points. It doesn't have to be perfect because it doesn't affect anything in the main line. When it's back to working, merge the branch in with the other working code. By the way, if you're looking for "the change that broke it", git-bisect is taylor made for that—if you're using `git`, of course.	[reply] [d/l]
Re: How to best control non-working code with source control? by merlyn (Sage) on Apr 11, 2008 at 17:46 UTC
This is just one of dozens of advantages of using a good distributed version tracker like Git. -- Randal L. Schwartz, Perl hacker	[reply]
Re: How to best control non-working code with source control? by tirwhan (Abbot) on Apr 12, 2008 at 08:30 UTC
I also recommend that you should look into using a distributed version control system like `git`. Take a look at git-cvsimport and git-cvsexportcommit for using git with a remote CVS repository. If your organisation wants to change its main repository to git it could then use git-cvsserver for those developers who want to continue using the CVS client for accessing the repository. All dogma is stupid.	[reply] [d/l] [select]
Re: How to best control non-working code with source control? by arc_of_descent (Hermit) on Apr 14, 2008 at 09:25 UTC
Yes, branching is the way to go. I'll also recommend you learn to use the svn switch command. Its very handy for switching between branches as well as the trunk. merlyn has a nice talk explaining git here -- Rohan	[reply]
Re: How to best control non-working code with source control? by locked_user sundialsvc4 (Abbot) on Apr 14, 2008 at 19:35 UTC
I think that you made a mistake by setting up your own CVS server. Version-control at a corporate level falls apart pretty-quickly when there are “sattelites.” I think that you needed to fork off your own branch, but that you needed to do so within the auspices of the version-control server (and system) that already existed in your organization. Not-every branch “survives.” Not-every branch ought to. “Branches” do not have to be “functional.” If you spin-off a part of the development effort into a version-control system that is entirely disjoint from the one that the enterprise as a whole is using, I fear that you will completely negate all of version control's benefits....
Re^2: How to best control non-working code with source control? by radiantmatrix (Parson) on Apr 15, 2008 at 18:02 UTC
I take your points about using branches, however: If you spin-off a part of the development effort into a version-control system that is entirely disjoint from the one that the enterprise as a whole is using That's not what I've done. Essentially, I have a "scratch" area where I can try things out, because the corp. policy says "no check-ins of non-working code". When I do fix a problem or add a feature, that immediately gets synced and checked into the corp. CVS -- so it isn't disjoint. I essentially did with CVS what git seems designed to do (and better) -- created a local version history for code that isn't ready to share with others yet. Based on your comment and others', it seems like the only real option I have is to try to get policy changed to allow me to create "unofficial" branches that contain non-working code, or to continue to do the bastardized process I have today. <–radiant.matrix–> Ramblings and references The Code that can be seen is not the true Code I haven't found a problem yet that can't be solved by a well-placed trebuchet	[reply]