meld --auto-merge argument

Nikolaj Sjujskij sterkrig at myopera.com
Mon Apr 8 05:44:07 CDT 2013


Den 2013-04-03 02:57:04 skrev Matt Mackall <mpm at selenic.com>:

> On Tue, 2013-04-02 at 10:43 +0200, Pierre-Yves David wrote:
>> On Mon, Apr 01, 2013 at 01:44:28PM -0500, Matt Mackall wrote:
>> > > Add --auto-merge, to enable automatic merging of all  
>> non-conflicting changes.
>> >
>> > Questionable. How long has the current release been out? If people
>> > install this on their gnarly old RHEL system, are they going to need  
>> to
>> > hack their config to work with their gnarly old meld? My guess is yes
>>
>> Mercurial instalation process does not install this configuration file.
>> Packager explicitly includes them in their package. I would trust[1] the
>> RHEL/Centos packagers to read the release note and handle the situation
>
> Who are these packagers? They're not listed on our downloads page.
>
> I'm not concerned about what >Redhat< does for RHEL. They package some
> version of Mercurial so ancient that it isn't relevant to this
> discussion.
>
> I'm concerned about organizations/individuals that (sensibly) build
> their own RPMs from our .spec files to backport recent Mercurial to
> their systems. There are MANY of these; I now work for one.
  Could .spec-file contain Meld version restriction? So repackager would  
get an error if his Meld package version is too old. I'm not familiar with  
RPM-based systems, so it's just a suggestion.

> Communicating to all of them that they need to upgrade meld or need to
> hack their scripts or revert our config change won't be easy. Having
> them discover the hard way that they need to upgrade meld or change the
> config is undesirable.
>
> (It'd be AWESOME if there was someone publicly and regularly packaging
> RHEL/Centos backports for the world, in which case I could reduce my
> concern factor here.)


More information about the Mercurial-devel mailing list