- About Us
I don't see any real holes in your concerns. It appears to me that, as is often the case, the problem is between keyboard and chair. The question is how technology can best address the issue. As you imply in your article, one of the goals of using revision control is to produce "perfect diffs". Ideally each bug fix or feature enhancement is a single "perfect diff". The right way to do this is to have each be it's own branch, which is a people problem. Each developer has to learn to manage multiple branches. This requires a bit of organization, but increases the likelyhood that any given branch will merge trouble-free because each branch touches less code and each branch is "smaller" and so can be completed in less time. Of course sometimes they'll be mistakes, where multiple changes are made to a single branch, and sometimes they'll be legitimate conflicts. The ability to analyze, cherry pick hunks, and otherwise resolve the conflicts is where rubber meets the road when it comes to source code management. From my armchair, without having actually used darcs or a lot of the alternatives, this is where darcs mathematical foundations should come to the fore and deliver real power into the hands of the developer. I can't say whether that power is enough to cut through the chaos of the development process. In line with your concerns, it probably depends on the developers, and therefore, indirectly, on good management personnel. I don't think that the discipline has truly developed good practice, which is partly a chicken-and-egg problem because you can't develop good practice without starting with good tools and you don't need powerful tools if you're locked into a rigid development process. Lots of branches works for me, but I've not managed a team in a while and I don't know how it would play out if I tried it with a team. I imagine the best approach would be to tailor each programmer's practice to their skill level. Some might be required to use a single branch and others left to manage their own work.
Someone knows the best way. It'd be nice to hear from that person.
Karl O. Pinc <firstname.lastname@example.org>