hg, git, fossil, ...

[Marko Rauhamaa]

Chris Angelico <rosuav at 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