Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

During a previous consulting position, the developers where told to check-in code on a nightly basis, regardless if it complied or was complete. Managers were afraid of losing any code and said now we only lose one day at most.

The place I'm currently it is investigating whether to implement this.

Anyone have any pros/cons on this? Should developers be forced into check-ins?

share|improve this question

migrated from stackoverflow.com Jan 6 '11 at 4:57

This question came from our site for professional and enthusiast programmers.

3  
what if they dont check in? will you fire them? –  Anonymous Feb 26 '10 at 23:12
9  
How exactly does checking in at the end of the day prevent lost work? It seems to me that "hit Save occasionally" and "don't put magnets in your workstation" are both more meaningful policies to have, and their ridiculousness [as policies] is illustrative. –  Ipsquiggle Mar 3 '10 at 17:41
3  
Please replace manager. –  user1249 Jan 6 '11 at 12:03
6  
How can you use continuous integration or even nightly build with such policy ? –  David Jan 6 '11 at 12:33
show 1 more comment

26 Answers

That has got to be the dumbest bit of dumb management I've ever heard of, if they really mean 'checked into the shared trunk.'

Reasonable solutions:

  1. Do work in task branches, and indeed check into those early and often.
  2. Run backups on the developer machines.
  3. Keep development trees on a shared file system and run backups on that.
share|improve this answer
9  
Yeah, if you're worried about losing developer's work, then back up the development machines. Don't check in broken code. –  Dean Harding Jan 6 '11 at 5:39
3  
+1: Use task branches. I like to commit every time the unit tests pass. If your VCS doesn't support task branches easily, then it's obsolete and you should replace it. Seriously. –  kevin cline Jan 26 '12 at 23:09
1  
@DeanHarding: I agree with the sentiment but the comment is over generalized. I would re-phrase to "Don't check in broken/unfinished code to trunk or any shared branch". I can see a processes where doing some complex refactoring I would check the code in multiple times before it is finished. I would make sure this is some completely separate branch that will never affect anybody else but checking in often allows you to rollback when your re-factoring goes down a wrong path. –  Loki Astari Aug 20 '12 at 6:39
show 1 more comment

Good luck trying to "force" developers into anything. The key is to make it the easiest path and let their laziness do the work for you!

It's usually a bad idea to check non-working code into a repository... the next guy that does a checkout gets a broken build.

If something is happening to destroy developers' work in progress, perhaps that is the problem that should be corrected.

Using a distributed versioning system that allows each developer to commit on their local machine and then handles all the merging between developers/versions might be a better solution.

share|improve this answer
1  
Agreed. OP - ask your managers if having the whole staff running down build breaks every morning is a "better" use of resources... –  DaveE Mar 3 '10 at 17:56
8  
Agree - use a distributed versioning control where the committers can commit whenever they want to locally, and then merge up when the stuff is ready to share with others. This gives you a better documentation trail. –  user1249 Jan 6 '11 at 5:25
5  
Working on a private branch, and committing to a central repo that is backed up solves both problems. Committing code to a branch only affects those using the branch (i.e. just you). However, it will now be backed up with the rest of the code in the central repository. Once the code is ready for others to use, it can be merged from the private branch to the trunk. Even if you're using a distributed VCS, you can still have a central repo. Work can continue if you drop or lose your laptop, or if you just get sick for a week - anyone else can check out your private branch and continue working. –  Stephen C. Steel Jan 6 '11 at 19:21
2  
Your annswer is a bit misleading. DVCS isn't the only answer. You can create a branch to do you work in and merge back to trunk. Some VCS have the concept of shelving explicitly for this reason. –  Andy Jan 27 '12 at 2:48
show 1 more comment

No, never check-in broken code, that will just get in the way of the guy coming in early next morning.

But delevopers should be encouraged to develop in iterations so small that they can check-in working (although maybe inactive / unreachable) code a couple of times a day. Then checking in working code before leaving is no problem.

share|improve this answer
add comment

Code that is not yet ready for inclusion in the 'trunk' should be placed in a shelveset. (TFS has direct support for this and I'm sure other source code control systems do too.)

Not only should checked-in code compile, it should pass all unit tests before inclusion in the 'trunk'.

share|improve this answer
add comment

No. Check-ins should never break a build. There are other ways to ensure code doesn't get lost (various backup strategies).

share|improve this answer
show 2 more comments

Personally I prefer to check in at least once a day. It's not always at the end of the day though. Sometimes I finish working on something and check it in with an hour left in the day. It's not enough time to get going on something else, so I get started and get it to a check-innable state the next day.

Uncompilable code in the repository seems like it's asking for trouble. What happens when someone checks that out? They get code that doesn't work and they're not sure if it's there machine, or the code, or if they did something wrong.

share|improve this answer
show 1 more comment

This is why DVC is a good idea. Developers can check in on their own machine whenever they like without messing up someone else's code.

As for backing up. For Git, I'd have a central server with copies of everyone's code accessible via ssh. Then as a commit hook, I'd have a script that would push changes to the server. This has the added bonus of making it easy to merge branches (as they're all on the same machine).

share|improve this answer
1  
+1 for DVCS. I do a commit every day, but if it's broken, I just push to my own private copy of the repository on the server, so I still have a backup, but the changes aren't public yet. When it compiles, then you can push it to the public shared repository. –  Scott Whitlock Jan 6 '11 at 11:56
show 4 more comments

Yes, but if it's not compilable, it shouldn't be committed to the trunk. It would be annoying if an employee kept checking in broken code that affected every other developer.

Maybe a branch per employee, that is specifcally for an end of day checkin, would be better.

share|improve this answer
add comment

If you break my build, I'm going to break something of yours. There is never, ever sufficient cause to check in code that does not work or compile. I repeat, there is never a good reason to check in code that does not work or compile.

I need, and expect that I can revert back to any revision in the history and end up with a working build. This is absolutely critical for me, and breaking this logic defeats one of the best purposes of version control.

If management is worried about losing code, disks are cheap. Ask developers to back up their files prior to leaving. I don't think that would be very cumbersome. Still, a well designed network should already be doing that, even if people tend to work on laptops that they take home at night.

share|improve this answer
add comment

This rule could even make productivity go down. Imagine you're working on something and you just finished a chunk that works and you're happy for that to be checked in (it won't break the build, etc.).

You then could start working on the next bit, but it's almost 5:30PM and you know that you won't be able to get the new code working before 6PM when you leave and would have to check in your unfinished code (which breaks the build, and you don't want to do that).

So you stop coding and go and do something else. It could be something useful, or maybe you're just browsing the web, checking email, etc. Therefore you could see that half hour as 'lost'. There is a good chance it happens multiple times a week, and among other developers in the office as well. So you could potentially lose hours of coding time a week, and surely the management wouldn't be too happy with that either...

share|improve this answer
add comment

Check in compilable code.

Shelve the non-compilable code.

share|improve this answer
add comment

I can understand management's motivation behind checking in every day. They're seeing it as a form of backup to a (presumably) central server, thus protecting their biggest asset, the source code.

In and of itself, there's nothing wrong with that, however, those "check-ins" should be made to a "work-in-progress" branch (if you're using something like SVN or even a DVCS like Git or Hg) or a "shelve-set" (if you're using TFS - this is exactly what shelve-sets are for!). The next day, developers can continue working on their own "work-in-progress" branch, and only merge with the trunk when work has been completed and all relevant tests (if any) have passed. Rinse, repeat.

Others have suggested that using a DVCS will address the problem, and sure, it allows devs to check-in to their own repository on their own machine, however, this is likely not management's intention behind their idea of daily check-ins. The likelihood is that they want all source code (both "finished" and "work-in-progress" code) to be stored on a central server somewhere. It's also then likely that this central server is either off-site, replicated or itself backed-up to tape etc.

In other words, the "check-in every day" policy isn't so bad so long as it's part of a policy that also ensures that your working main trunk is not polluted with unfinished work.

share|improve this answer
show 3 more comments

I've always advocated checking in regularly (i.e. more than once a day), but only checking in code that compiles. Even if a feature isn't 100% complete, it provides earlier oportunities to determine if the work in progress is going to affect other parts of the code.

Here's an example of what your company is (hopefully) trying to avoid:

Many moons ago, I had a borrowed developer working on an IR&D project. Despite me badgering him to check his code in every day for a month he wouldn't do it. When he finally did check in the code it was working as long as there was only ever one user at a time. By developing a Java web application like a C project (everything was a static method, aka function) he caused a whole mess of rework for the rest of the team.

There are similar horror stories such as the original IR&D developer not using version control at all, and the current version of the software was in his local directory on his machine instead of the file server. He left the company, leaving the IR&D project high and dry (which is why I was brought in and dealt with the situation above).

That said, I'd rather know that there are issues and design choices that need to be addressed earlier rather than later. However, the trunk should always compile. I've never left for the day with a broken build. Whatever your solution, keep in mind the cautionary tale of the developer who wouldn't check in code, but also keep in mind the horror of the first person arriving for the day having to fix everyone's code before they can continue.

As with all things, there needs to be a healthy balance.


Edit If you ever do find yourself "blessed" with a developer who refuses to check in code for an extended period of time, you have some other problems that you need to resolve. If they refuse to check in their code, insist on a code review--you need some assurance that the code is going to function in your environment when it finally is. If they refuse that, they probably shouldn't be on your project at all.

share|improve this answer
add comment

I think management is wrong to say even if it doesn't compile. You should check in every day and it should compile. You really shouldn't have multiple days worth of work that isn't in the repository somewhere. But you also shouldn't be flying along writing code that doesn't copmpile for days at a time.

If you make an effort to conform with both of these rules, you will learn to work in small pieces and have a better handle on what you have done and how close you are to your goal.

share|improve this answer
add comment

I guess it's good that they know what version control is, but they're mistaking it for a backup solution.

Even if developers did this, and it didn't cause complete mayhem (big IFs!), what about all the non-code work that developers do? I've got lots of other things (local config files, browser bookmarks, etc.) that would also be lost without backups.

share|improve this answer
add comment

Shelving your code at close of business is a better option than checking in the code.

share|improve this answer
1  
Checking in the code to a private branch is better than shelving, because it gives you multiple checkpoints. –  kevin cline Jan 26 '12 at 23:12
show 1 more comment

Use a DVCS like GIT. Commit things that work and pass the unit tests. The rest that is not done yet, just stash it on your local machine and have a good evening and night.

share|improve this answer
show 1 more comment

That's definitely a good idea if it compiles and passes the unit test. Otherwise no.

share|improve this answer
add comment

This is a solution to problems that aren't related to programming tasks. You're either solving an issue where data has been lost due to machine failures or where work has been inaccessible because someone left for vacation and their machine was locked. Neither of those problems should be addressed by breaking how source control works.

share|improve this answer
add comment

If the workflow within the company is such that every check-in gets included in the nightly build automatically, then the check-ins must not break the build under any condition.
If the manager does not understand how bad it is to break the build, ask him who is going to explain to the management of the testers why they have not received any new versions to test for the last three weeks. And to upper management why we have not been able to meet the scheduled release dates.

If additional steps are needed before a check-in gets included in a build, then it is not a big deal to use such check-ins also as a backup procedure, although real backups would be preferable, if only because they don't/shouldn't require active actions by every developer.

share|improve this answer
add comment

The simple answer is no - if its broken or if its not finished then it shouldn't be committed. Version Control should not mindlessly be used as a backup system.

If they want backups they (management) should implement a backup solution - either explicit or implicit.

The real answer is more complex as has been identified by various people - but DVCS, for example, won't provide a backup unless the committed code is immediately (and automagically) pushed to a clone - of the Work In Progress - on another box.

So the bottom line is this - even if you have a structure in your VCS that allows commit early and commit often of notionally failing code by having a safe work in progress branch (that's another discussion) you should still have an independent backup solution.

share|improve this answer
add comment

We have a policy that developers should shelve their code in TFS before they leave. This allows code to be saved and backed up without breaking the build.

share|improve this answer
add comment

If it breaks the build don't commit it. If management still want code checked in organize a separate branch for the non-compiling code and then devs can commit their broken code to that branch.

share|improve this answer
add comment

The rule of thumb that I've always heard is as follows:

Code doesn't exist until it has been checked into source control.

So my usual policy is that code should be check in on the basis of the completion of function, classes, etc as opposed to fixed times through out the day. If you are only checking in once a day then if something happens to your computer, you lose a lot more work than if you are checking in every time you are able to close out an issue ticket.

That said, where a project is in the life-cycle affects what you want to be doing with it. When you are still in the process of developing a new program from scratch you might be a bit more forgiving than if you are working the maintenance of an existing application.

Also, how the code is broken also makes a difference as well. If the requirement is for a function to be rewritten and you are only half done when it's time to call it a day then I say just update the code in such a way that it will compile and then raise some sort of flag such as System.NotImplementedException so others know what is going on. If you ripped out a bunch of code that affects several different parts of the application then it might be better to leave it out of source control so you don't disturb others work.

share|improve this answer
add comment

We had this policy at my last job, and it was never really problematic. We had user.daily or feature.daily branches for code that didn't compile or run, and once the code built and had undergone some basic testing (it doesn't segfault as soon as you run it, etc.) then it would get merged into the feature branch. Once a feature was complete and unit tested it would get merged into the master branch. This way nobody's build was ever unexpectedly broken, and we had code being stored somewhere other than the developers workstations.

share|improve this answer
add comment

Requiring developers to commit code at the end of the day is crazy, but unless you are a developer its easy to see how it would make sense.

As developers, you shouldn't really go longer than a day without committing code anyways ... if it is going to take longer than a day to write a single unit of change (or whatever unit of measurement you use to justify a commit) then you should probably have broken it down into a smaller change anyways. If those multiple changes belong to a bigger feature, it should be on a separate branch anyway.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.