hg, git, fossil, ...

[Chris Angelico]

On Fri, Aug 29, 2014 at 5:37 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> 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.

Very frequently I've moved patches around that affect just one
function in one file. There's some granularity at the file level, some
at the function level, some at the class level (if you have that
concept in your repo), etc, etc, etc. You'll find changes that affect
one of any of the above.

>> 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.

You're talking about a file having never changed across nine Python
releases, which happen roughly every year and a half. That's a file
that doesn't change for well over a decade, and now you want to
backport a change across all those releases. Even allowing for some
measure of exaggeration (CPython doesn't release patches for that many
versions), I'm still dubious that there hasn't been any sort of
sweeping change in that much time.

>> 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.

Yes, cherry-picking happens. And in git, it's really easy. Ditto with
'hg graft', I'm sure, although I've never used it so Tim Delaney may
have to confirm that. If the file really hasn't changed, then the
cherry-pick will work.

ChrisA