Committing broken code to the repository for the purpose of backing it up

Question

I was just talking to another developer (more senior than I) and trying to convince him that we should implement continuous integration via Cruise Control. He told me that this will not work because he commits code that does not compile to the repository all the time for the purposes of backing it up. And that automated builds notifying us of failures would be just noise.

Committing garbage to the repo sounds bad to me. But I was at a loss of words and didn't know what to say. What is the alternative? What's the best practice for backing up your code on another machine without adding a bunch of pointless revisions?

BTW, our version control system is SVN and that probably won't change any time soon.

Summerly

I was about to say "use git!", but then I saw the last part of your post... – Deathly

That's why I added it ;) – Summerly

Sorry.. Your senior dev checks in code that doesn't work, and considers this a good thing? You poor *******. – Misfire

So you want to propose a backup solution to your senior without knowing what or why he wants to back up? Don't you think you should understand the problem before looking for solutions? – Alexandros

@Alexandros I don't really get your comment. We're talking about code source files, so that's clearly what he wants to back up. And I'm guessing he's paranoid about losing his work, so that's the why. – Summerly

Answer 1

Develop in branches and commit ready to test and hopefully working branches into the main line. Let the continuous integration server depend on the main line (in svn most times called trunk) for new revisions to build and validate.

Friedrick

Answer 2

How exactly does everyone else on your team compile if he's checking in code that doesn't compile?

In general, I think it's a faux-pas to check in code to your main branch that does not compile; it's really inconsiderate to anyone else who's counting on being able to get latest from source control and build.

TFS has some nice features to help out this issue (shelve/unshelve); not sure if SVN does or not. Most of the time when someone is working on a huge change and they need to be able to check-in broken code, it's better to branch, and have them merge changes to the main line.

Assimilate

Answer 3

If you're checking in broken code to a branch that other developers are expected to be using, and not maintaining a line of communication about that and doing it for some good reason... well, your coworker isn't following best practices.

A mutually-acceptable best practice may be to require "break the build" type "backup" checkins to happen on a developer-private branch of the code, and whenever code is in a state that won't break the build or unit tests, it gets merged to a trunk branch that Cruise Control is watching.

Maxillary

Answer 4

Unless he is the only developer on the branch (which sounds like it isn't the case) then he should not be committing back breaking code. There exist dozens of solutions for 'backing up' code in development, including just creating a private branch of the current line or writing a small script that backs up the working directory to a fileserver.

Famagusta

Answer 5

Use git for local backups/history, and git-svn tools to check in only the working versions.

Bliss