On Fri, 20 Oct 2006, Aaron Bentley wrote: > > > > Btw, this is a pet peeve of mine, and it is not at all restricted to > > the SCM world. > > I guess I don't mind a bit of high-mmv discussion, so long as it doesn't > get in the way of real work. Polishing these kinds of things seems to > fall in the category of 10% of functionality that takes 90% of effort. Well, the thing is, that 10% of the functionality usually takes a whole lot _less_ than 10% of the work. The stuff you can think through (and argue about) tends to be the easy stuff. Exactly because you _can_ think about it abstractly. The stuff that is actually really hard and time-consuming is the stuff that you find out in practice, and you have to iterate on. In kernels, for example, it seems like 99% of the effort ends up being hardware-dependent stuff. Getting architecture interfaces right, and getting working drivers. Hotplugging and device management turns out to be a _much_ bigger issue than schedulers or VM page-out has _ever_ been. But show me a single paper about them. I'm sure they exist. I'm just saying that they're sure as heck not getting 99% of the attention (or even 1% of the attention) in discussions, even though they're definitely 99% of the real everyday work and effort. (Maybe it's not 99%. Numbers taken out of my nether regions. The point should be clear). The same is actually true of SCM's too, I'm totally convinced. At least in git, we really haven't spent _that_ much time on merges, for example. My original stupid three-way merge was really simple, and I think the way I introduced "stages" into the git index was really clever, but it was still a small detail. And it worked surprisingly way. After that merge, people improved it. And "recursive" is a _huge_ improvement, don't get me wrong: it's still entirely a 3-way merge on the file contents, but it now does those 3-way merges in several stages if there are multiple independent common parents, and the rename logic is clearly important. But if you actually look at how much effort was spent on merging, and how much was spent on just "details in general", I think you'll find merging to be pretty low down the list, even though the recursive merge ended up _also_ getting re-written in C. Perhaps it was one of the bigger _individual_ efforts, but compared to all the work we've continually done on performance and usability, for example, it's been pretty small in the end. As an example: I suspect that in git just the CVS importer has gotten _way_ more attention than merging ever got. Importing from CVS is simply a much harder problem in practice, and we've probably had more people working on it (and that's _despite_ the fact that this is one of the areas where git has successfully re-used other projects that had similar goals: cvsps, cvs2svn etc). It's hard to "think" about, because a lot of the problems with importing from CVS are literally all about the details and the nasty crud. I really think "merging" is _way_ easier. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html