3

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?

Improve this question

5 Answers 5

Reset to default
1

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

Improve this answer
2
  • 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. Commented May 26, 2011 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 :) Commented May 27, 2011 at 11:41
2

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.
Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.