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?
Regards,
Michael
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.
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.
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:
No. Check-ins should never break a build. There are other ways to ensure code doesn't get lost (various backup strategies).
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.
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.
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.
That's definitely a good idea if it compiles and passes the unit test. Otherwise no.
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'.
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...
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.
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.