▲ 15 points
back
6 comments
I find myself working this way almost all the time. In the middle of a refactoring or other change, I try as much as possible to get it commited by the end of the day, in a runnable state, even if accessing the affected unfinished area will crash. Better that than to have to walk in the next morning and try to remember what portion of the code change is actually finished.
In a way this is like looking at your changes as atomic operations: If a change is so big you can't get yourself back into a runnable state by the end of one day coding, it probably should be broken up into smaller stable steps.
For bigger changes I just work over a new branch.
This is great advice, but it requires significant project discipline to make it work with large projects. Breaking builds or introducing bugs that make your coworker's jobs harder is a cost you need to look at. Tools like git, with per-developer "branches" might be a good choice.
But I fear that it a typical team is told to check their changes in every few hours, this is going to cause more harm than good.
But I fear that it a typical team is told to check their changes in every few hours, this is going to cause more harm than good.
Let's examine the "typical team" scenario.
1. Can't tell everyone to check in changes every few hours, because it'll hopelessly break everyone's builds all the time.
2. Can't tell everyone to only check in concrete working chunks, because then people will only check in once every week. Unless people work on isolated components, this will have a tendency to make merging progressively harder.
3. In CVS and Subversion, can't tell people to use private branches, because manual merge tracking means that revisions in non-trivial branches can get lost. (This happened to me on several occasions, and the main reason why I hate, loathe, and despise Subversion.)
4. Can't tell people to use distributed source control, for a variety of reasons. Politics. Fear of change. Lack of IDE integration, for the majority of "typical teams" out there who do not understand command line tools. Lack of interest in learning better tools ("this already works for us," and never mind that you just spent a week before the release unravelling the mess everyone made of the Subversion repository). Stuff like "git rebase --interactive" and "git add --patch" is easy to use, but I personally have found it enormously difficult to explain to other people the value of clean, well-ordered, well-isolated revisions.
Basically, in a team where everyone proficiently, comfortably, and cleanly wields git or hg, source control shouldn't be a problem. In any other team, there will be problems. On my current project, I've been keeping my life sane by using git-svn, but the rest of the team can't and won't adopt better tools, and it struggles with the Subversion soup.
It scares me to think that many programmers are not comfortable with the command-line. Sure, GUI integration is nice, but I actually prefer using Git from the command line for most things, except for viewing history (Gitk/Giggle) or differences (Kompare.)
The way Jeff talks, one would say he doesn't know about git-svn: commit locally a zillion times, then just push once to the remote, shared svn server.
Which is to say: the fear of "breaking the build" should not stop you from doing anything you want locally.