And I don’t see it as a really strict working policy if you say: “Only commit stuff that works”.

If you’re talking about trunk, I’m with you. Otherwise, I don’t really see your point.

@Zonium, Repsah: I think I was a bit imprecise with the term “incomplete” as there are two different cases. On the one hand there are the “good” cases, e.g. committing a form together with an empty action. Even though this feature is incomplete, it doesn’t break anything. On the other hand there are the “bad” cases which break stuff, e.g. renaming a method and committing this change, without adapting and committing the code which uses this method.

But if there are tests around, then I think they should pass before you commit your code as it is annoying to have a red bar ;-) And it shouldn’t take you long to make them pass if you move forward with small steps anyway.

I agree with you that you shouldn’t defer a commit for too long (I experienced the negative effect of this more than once myself *g*). I think the motto “release early, release often” also applies for commits.

@Ben: Thanks, you bring it on the point :)

@Brendon: Sure, it is my own decision to use the latest code and I am aware that I am using an unstable version. But “unstable” means for me that things may change and are not yet finalized, but not that it is buggy by intention.

I agree with you that every team/person has its own way to work, and what works for some, may not work for others. That’s ok. On the other hand nobody is perfect, so there is always room to become better. This article may be an inspiration for you to question your own way of committing stuff. I don’t expect everyone will now start using this approach ;-)

@Jeff: Thanks for sharing this link!

@Eelco: Well, I think it makes sense to follow the same approach when working alone so that it becomes a habit.

@brandon: That makes sense. A similar approach was used in a company I worked in the past. There were also three stages (dev, staging, live), but only one branch was used for the dev site. If you wanted to put something to the staging server you simply exported the code from the dev branch. And to go live the code was copied from the staging server. This worked fine at that time and you didn’t have to care about merging ;-)

@John: Well, this article is meant as feedback on how the commit process could be improved. And yes, it is written from my perspective: I described what I think the problem is, and I described what I think could be done to avoid it. Now it is up to you what you do with it ;-)

Essentially, it boils down to “it wasn’t done my way.”

We have both a live site and a live-dev site. The live is checkout’ed to the trunk and the live-dev is a checkout of the ./branches/dev (www.site.com and dev.site.com respectively).

Obviously committing partial or incomplete code to the dev branch could render our live-dev site useless. So on each of our local devs we use the “private branch”. Our flow goes:

Private Branch -> Public Branch -> Public Trunk

Only the devs have access to RW on the private branch. We add specific keywords to commit messages so the other developers always know what they are and which revisions need merged:

- Critical / Bug Fix (almost always immediately merged)
- Enhancement
- Partial (never merged by itself)
- Complete Partial [partial revs list]
- etc..

After they are in the public branch for 1 week then they are set to be merged to the public trunk. (Each commit goes through a 1 week “test” period)

FYI, don’t try to manage SVN merges by yourself. There are many tools out there (svnmerge, etc) that help with managing these.

When I’m the only one working on a project it doesn’t really matter.

http://netevil.org/blog/2006/dec/coding-for-source-control

Seems like you’re grasping at straws here… ?

The thing here, is that many teams work in many different ways. To expect one team to always work like another is irresponsible. Certain teams work better one way, others another. If there were two branches – a developer and public, perhaps it would be helpful, but then…you’d need to commit time and resources to keeping the public branch updated – time that could otherwise be spent on the code itself.

I think in the case of CakePHP, the way they’re going about it is probably the fastest and best possible solution. If you want to be bleeding edge with the source, you’ll have to deal with a few (or more) stumbling roadblocks. :)