hg, git, fossil, ...
Terry Reedy
tjreedy at udel.edu
Thu Aug 28 13:40:30 EDT 2014
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
More information about the Python-list
mailing list