Chris Angelico <ros...@gmail.com>: > What you're saying, though, is that there's something inherently > special about file boundaries. You want files to be magically > separable within a repo. Why? What's the significance of the file?
Files do have that magic property. That's only an approximation, but it is a very accurate and fitting approximation. Developers have a strong tendency of collecting functions to files. More to the point, functionality may be split across multiple files, but a large repository is far too blunt an abstraction. As I have mentioned, Darcs tries to get everything right. I haven't used it, but I have read it sometimes gets entangled in its smart algorithms. > In reality, it's highly unlikely that this simple fix is the only > change that's ever occurred to that file, so I very much doubt that > your proposal would even work. I have actually found the reverse to be true. Most fixes are very local, and in large repositories, most files don't experience any change for over numerous releases. > With git/hg, the merge is exactly the same whether there've been > changes to other files or changes to other parts of the same file, > because file boundaries just aren't that special. This is basically a > cherry-picking job; Yes, that's cherry-picking. You also have manual patching and manual editing. All methods are in use, manual editing in particular. That's because of the awkward repo-level abstraction. Marko -- https://mail.python.org/mailman/listinfo/python-list
