hg, git, fossil, ...

[Terry Reedy]

On 8/28/2014 12:17 PM, Marko Rauhamaa wrote:

> Imagine we have CPython 3.9. It might have an ancient implementation of
> the deque. Then somebody realizes there's an embarrassing bug that
> requires a simple fix in a C file. The fix is implemented in HEAD. Then,
> it is propagated down to 3.9, 3.8, ... 3.0.

For CPython and mecurial, that is the wrong direction. We start with the 
earliest branch and merge forward. Security fixes start with 3.2, bug 
fixes with 3.4.

> You obviously couldn't use "hg pull" for the propagation

One uses hg merge to merge, so this does not make sense.

 > since hg would insist on propagating all
> the unrelated features as well.

Once a patch has been pushed, others pull it. So one does use hg pull 
for propagation in that sense. For each branch, one gets the patches 
that have been applied to the branch, as one should. It is our intention 
that each changeset, whether applied to one or many files, leaves the 
repository in a coherent state.

-- 
Terry Jan Reedy