On Fri, Feb 12, 2010 at 09:39, Georg Brandl <g.bra...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
