This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zach.ware
Recipients BreamoreBoy, loewis, steve.dower, terry.reedy, tim.golden, trent, zach.ware
Date 2014-10-27.21:46:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1414446372.73.0.178783886161.issue17896@psf.upfronthosting.co.za>
In-reply-to
Content
Basically, after:

hg clone h.p.o/cpython default
hg share default 3.4
hg share default 2.7
hg -R 3.4 update 3.4
hg -R 2.7 update 2.7

the 2.7, 3.4, and default directories are separate working copies created from the same history, each at a different revision.  As soon as a changeset is created in one, it's available in the others (but the other working copies don't change).  So after commiting to 2.7 (from within the 2.7 dir), `cd ..\3.4 && hg graft 2.7` will try to graft your new changeset to 3.4, then `cd ..\default && hg merge 3.4` will merge it with default.  hg push will push the same thing from any of the three directories.
History
Date User Action Args
2014-10-27 21:46:12zach.waresetrecipients: + zach.ware, loewis, terry.reedy, tim.golden, trent, BreamoreBoy, steve.dower
2014-10-27 21:46:12zach.waresetmessageid: <1414446372.73.0.178783886161.issue17896@psf.upfronthosting.co.za>
2014-10-27 21:46:12zach.warelinkissue17896 messages
2014-10-27 21:46:12zach.warecreate