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.

Working on a project with a couple of classmates, and I've noticed that we get a lot of partial commits which are then corrected:

Rev 249 Log: committing change foo, yeah!
Rev 250 log: oh dear, forgot these files!
Rev 251 log: oh my, how could I possibly forget another file in the *same* change?

The obvious answer is to be more careful. But as of 2011, programmers are still (almost) human, and are error prone. The problem is that this causes ambiguity when reverting or merging. Do we leave them there? Do we modify the commit history?

share|improve this question

5 Answers 5

up vote 1 down vote accepted

You could use continuous integration, but it seems overkill for a class project.

If using your own server, you can run scripts (called hooks in SVN) before accepting a build. So you could do a simplified continuous integration that runs a command line build on the server before allowing the commit. Or devise a custom script that checks for missing files (by parsing makefiles or Visual projects or whatever you use).

share|improve this answer
    
Thanks. The reason I accepted this and not the at the moment top-voted answer is that this way trumps the human errors that eventually creep in - even though both together is of course ideal. –  Max May 26 '11 at 6:09
    
Oh and I suggested this as I knew many people were going to mention DCVS, although I think a good use of a DCVS (git, Hg come to mind as 'mature') use local commits + shared repos could help a lot... IF people take a good care. The script approach is sure safer :) –  jv42 May 27 '11 at 11:41

Get your developers into the habit of doing these four easy commit steps to keep that from happening:

  • Do your project's equivalent of make clean.
  • Do your version control system's equivalent of diff from the top of the tree that was checked out.
  • Go through the results and check that each change is what you think it is (i.e., that no unrelated changes were included while working on this one).
  • Commit everything from the top of the tree.
share|improve this answer

I would suggest that whoever has made the mistake on the commit gets to handle any merge pain. You shouldn't modify the commit history - it's there to track what changes were in what revision.

If this happens a lot then get people to commit to a user branch first and do a clean checkout and build before merging their changes back into trunk.

share|improve this answer

You could use a VCS that lets you (cough) "amend" earlier commits.

git isn't the answer to EVERY version control question, but it's certainly the answer to many of them.

share|improve this answer

If you use git and you haven't pushed to the server yet, you can use rebase to rewrite those commits and squash all the changes into one commit.

share|improve this answer

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.