On Fri, 20 Oct 2006, Jan Hudec wrote: > > Let's consider following scenario: Here's a real-life schenario that we hit several times with BK over the years: - take a real repository, and a patch that gets discussed that adds a new file. - take two different people applying that patch to their trees (or, do the equivalent thing, which is to just create the same filename independently, because the solution is obvious - and the same - to both developers). - now, have somebody merge both of those two peoples trees (eg me) - have the two people continue to use their trees, modifying it, and getting merged. Trust me, this isn't even _unlikely_. It happens. And it's a serious problem for a file-ID case. Why? Because you have two different file ID's for the same pathname. (It happily only happened a handful of times, so it was never a big enough problem to cause me to think that BK was crap. But it definitely was a real issue). What BK did (and what is likely the only reasonable thing to do) is to move one of the file-ID's to an "Attic" kind of place, and just go with the other. The nasty part is that now the developer whose file was "dropped" (and anybody who got the work from him) may still be continuing to work with _his_ copy of the same file, never even realizing that when his work gets merged, all his fixes GET THROWN AWAY! And trust me, this isn't a theoretical thing. This actually happens. So you have problems at many levels: you have the problems that happen during the merge (where somebody needs to decide how to resolve the file-ID clash), but what a lot of SCM people seem to not have understood is that the problem actually _remains_ after the merge, and causes problems even down the line. So yeah, content-based merging has its own problems (especially if you do things like re-indent a file as you move it, or if you have files that just look the same because they share 99% of their content through a copyright message), but at least so far, we've not really ever hit that issue in the kernel. And we are actually approaching the old kernel BK tree in size with the current git tree (we're about 2/3rds of the way if you count number of commits). That's despite the fact that we actually have been moving things around. So from a purely _practical_ standpoint, I really do have anecdotal evidence that I'm right. I didn't have that evidence when I started, but I knew I was right anyway ;) Linus PS. It's undoubtedly true that the SCM you use impacts _how_ you do development, so any project will almost automatically align itself with whatever SCM rules there are in place. So "anecdotal evidence" in that sense isn't really wonderful, since it obviously is always a matter of a certain project/SCM combination - but the above example is about as neutral as you can get, since it's the _same_ project, with the _same_ maintainer, and roughtly the _same_ rules, just two different approaches wrt renames of the SCM's in question. - 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