Useful Scripts for CM?

Question

I'll be forming a remote team, and I want to be able to use scripts (or something) to make sure that people's code is checked in every night. I currently use some BASH scripts that are kindof wonky and aren't customizable easily.

Does anyone have any useful tools, tips, or resources for this?
Are there any pitfalls to doing this that I'm not seeing, or can I do it better another way?

(cross-posted to super-user)

Answer 1

Why do you want to be sure that everyone's code is checked in overnight?

You don't want your build to fail and having to check code in implies that one will have to commit code that won't necessarily be right.

This leads to broader questions about what version control tools you're using and your general "philosophy" for version control.

Certainly you want to make sure that your developers work is backed up and you almost certainly want them committing changes early and often but equally you want, no, need a build server and you therefore want committed code to build (and pass its tests).

A lot of the answer may come from using a Distributed VCS (or teaming local DVCS with a central server based system) in that you can require "local" commits (pushed to a mirror for backup) - hence need for more detail or more questions...

• Stephen Furlani: DVCS like git or hg, right? So you're saying VC shouldn't be used in terms of backup?
• Cascabel: @Stephen: You can certainly use a VCS for backup, but the nice way to do it is via small incremental local commits (in a DVCS), which will get squashed and cleaned up before being pushed/published. Still, you should make those incremental commits when you're ready, not necessarily when you leave for the day.
• Murph: @Stephen - your VCS is, yes, a form of backup (and you need a "server" - I need to write more...) but if you want the security of end of day backups you ought to find something that is suited to daily backups to complement your VCS. I'll try and add some more to the above if it helps.

Answer 2

Why do you want to force people to check in code ? Doesn't seem like a good idea to me; if the developer is not ready to commit changes, there is probably a good reason.

What is the benefit to be gained from being forced to check in everyday ?

I have half built stuff that I wouldn't wish on anyone.

Every place I have worked the checked in code is assumed to work, or has passed tests and compiles correctly etc.

I'd set up a continuous integration server, hudson, in conjunction with subversion or cvs.

(backing-up should be different to checking in, imho)

• Stephen Furlani: I'm not sure I understand. I check code in daily so that I keep track of all my code, and it makes it real easy to roll-back changes. I don't consider "checked" code to be final in any sense. I also don't lose anything in case of disk failure or major SNAFU like rm -r *.m when I mean rm -r *.n
• NimChimpsky: How may developers are using the same codebase ? Do you all check in every day ? Where is your production code kept ?
• Stephen Furlani: If we release a version, it'll probably be a tagged snapshot of the source. I consider the trunk a working directory. Is this totally wrong?
• Murph: A lot of us would assume that we can build committed code (and that it should run and pass tests), certainly a lot of us would be deeply unhappy to commit code that didn't just to back it up.
• Stephen Furlani: @Murph, I hadn't considered that. This is the first time I've done something like this, and the last place I worked used no VC at all. It was a nightmare.

Answer 3

There's no real reason for not using revision control as a form of backup, as long as you have a backup plan for your repository.

If you are willing to educate your developers and administer your revision control system of choice, you can use tags and/or branches to handle the broken code issue.

As a matter of fact, I think that tagging (or branching) your release, beta and alpha code is the best way to go. This way it requires an active decision to screw up your released product instead of an 'oh shit' moment by a developer.