Georg Brandl writes: > What I really want to see is the common-subset approach for > maintenance branches.
IMO, this unfortunately unlikely to work as you seem to expect, for a two technical reasons and for a social reason. The first technical reason is that a maintenance branch really is a branch, not a subset. The fix that is appropriate for a maintenance branch is often inappropriate in detail for the mainline, and vice versa. But Mercurial doesn't care about "in detail" vs. "in design"; both will result in a conflict the first time that branch is merged. Second, some fixes for the maintenance branch will simply not be appropriate for the development branch, as the problem has already been fixed "en passant" by some other change. This can probably be handled by doing what git calls an "ours" merge to make it look like the unnecessary patch is an ancestor of the tip, even though no code was actually applied to the mainline. However, this kind of operation is some what delicate, and even if it's mostly scripted, it's likely to be somewhat unreliable for people who don't use the script very often ... which leads to the social problem: > > - our committers consistently refuse to merge changes across > > branches themselves, and likely continue to do so unless there > > is some feature of hg that I missed (e.g. one were merging > > would happen without any user specifically asking for it) > > If the checkin is done in the proper (the maint) branch, at least merging > of that change is automatic whenever someone does a hg merge. Maybe. But I see two problematic sides to this from the social point of view, which is the same old problem really. First, to the extent that it doesn't run into the technical problems, it encourages people to *not* review patches for each branch they are committed to. "It will get automerged anyway." Anything that discourages review is a bad thing. It will cause the development branch to "age" faster because of accumulation of crufty patches that are good enough as minimally invasive fixes for bugs in a maintenance branch, but which should be more robust for the development branch. I think you will also find that some people are not particularly interested in fixing the maintenance branch for some of their patches for exactly the same reasons they currently don't, and they will continue to refuse to do the work to commit in the maintenance branch first. Especially after the first time they run into one of the technical problems described above. In the end, any policy to encourage a "subset" policy is likely to end up as a burden on the same people who currently do the cross branch merging. _______________________________________________ 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
