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.

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)

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

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...

share|improve this answer
    
DVCS like git or hg, right? So you're saying VC shouldn't be used in terms of backup? –  Stephen Furlani Nov 18 '10 at 13:41
2  
@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. –  Jefromi Nov 18 '10 at 16:35
    
@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. –  Murph Nov 18 '10 at 22:21
add comment

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)

share|improve this answer
    
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 –  Stephen Furlani Nov 18 '10 at 13:34
    
How may developers are using the same codebase ? Do you all check in every day ? Where is your production code kept ? –  NimChimpsky Nov 18 '10 at 13:36
    
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? –  Stephen Furlani Nov 18 '10 at 13:37
4  
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. –  Murph Nov 18 '10 at 13:39
    
@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. –  Stephen Furlani Nov 18 '10 at 13:42
add comment

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.

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.