[Python-Dev] PEP 385 progress report

[Dirkjan Ochtman]

On Fri, Feb 12, 2010 at 09:39, Georg Brandl <g.brandl at gmx.net> wrote:
> No, it does not.  This is also a concern for the Python 2 -> Python 3 merging,
> where (I think) we decided not to have shared history.  Transplant already

I don't think this is similar to 2 vs. 3, because 2 vs. 3 are full
branching (so you could still use "normal" hg merge tracking there).
Since hg doesn't do merge tracking on the directory level, you
couldn't use Mercurial merges (or transplant, AFAICS) to do what you
want here.

> does most of the job (including recording the source hash of transplanted
> changesets), but it lacks blocking and consistent rejection of already-merged
> changesets (it does not read the source hashes it records, but keeps a local
> cache of such hashes instead, which obviously doesn't do anything across
> repositories.)  I think it should be possible to have transplant regenerate
> and update that cache automatically on clone/pull/etc.
>
> I guess this is a relatively simple task for a Mercurial hacker, and if it's
> decided to use this workflow "someone" ;) could address it at the PyCon sprint.

Yes, we should figure out some workflow issues soon.

Cheers,

Dirkjan