[Bug 466300] New: Wrong default setting of mercurial
https://bugzilla.novell.com/show_bug.cgi?id=466300 Summary: Wrong default setting of mercurial Classification: openSUSE Product: openSUSE 11.1 Version: RC 2 Platform: i686 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: pth@novell.com ReportedBy: alpar@cs.elte.hu QAContact: qa@suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121300 SUSE/3.0.5-1.1 Firefox/3.0.5 The file /etc/mercurial/hgrc.d/hgext.rc turns on a lot of extensions by default. Sometimes this can causes problems. For example inotify extension has a bug related to 'hg st' and 'hg revert' command (see http://www.selenic.com/mercurial/bts/issue1468). It is also against the policy of the mercurial developers. See this message from the mercurial mailing list:
Somehow this [i.e.: the inotify extension is turned on] is the default setting in the mercurial provided by openSuse 11.1.
If you're sure about that, you may also want to file a bug about that. Distros should ship hg with all extensions disabled by default.
Cheers,
Dirkjan
Reproducible: Always Steps to Reproduce: $ su $ zypper in mercurial $ /etc/mercurial/hgrc.d/hgext.rc Actual Results: You will see the default settings. :) A lot of extension is turned on. Expected Results: All the extension should be turned off. The same problem occurs with the newer mercurial version provided by http://download.opensuse.org/repositories/devel:/languages:/erlang/openSUSE_... I have no idea where to report it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
Philipp Thomas
https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c1
Takashi Iwai
https://bugzilla.novell.com/show_bug.cgi?id=466300
User alpar@cs.elte.hu added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c2
--- Comment #2 from Alpar Juttner
Well, the current hgext.rc originally comes from Debain. So, blame them first :)
Yes, it turned out on the mailing list that Debian suffers from the same problem.
Apart from that, a bug is a bug, no matter what the default is. It must be fixed in anyway. It's just misleading as if the problem is the default extensions.
If we have a problem in inotify extension, please create another bug report.
I created an issue about it at mercurial's own issue tracker: http://www.selenic.com/mercurial/bts/issue1468
About the developer's "policy" -- is any reasoning given?
Plugins often change the substantially default behavior of the subcommands (meaning of switches, format of output), therefore can surprise users and can break other tools using mercurial. Due to the changed behavior, some of them (e.g. the 'purge' plugin) are even dangerous if the user is not aware of that they are turned on or (s)he is not familiar with them. Loading several unneeded plugins will also increase the start up time. Moreover, as far as I understand, mercurials provides less strict backward compatibility and stability for the plugins than for the core. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c3
--- Comment #3 from Takashi Iwai
Plugins often change the substantially default behavior of the subcommands (meaning of switches, format of output), therefore can surprise users and can break other tools using mercurial. Due to the changed behavior, some of them (e.g. the 'purge' plugin) are even dangerous if the user is not aware of that they are turned on or (s)he is not familiar with them.
OTOH, I've got already bug reports several times that some extensions were disabled as default. Thus, from the usability POV, "disabling all" is no good choice at all. I'd be annoyed if I would have to change my hgrc at each time I install on new systems just for basic extensions like mq. Moreover, the change of command behavior can be seen even often for the hg core commands. I don't think there is much difference between the core and the extension commands in this regard.
Loading several unneeded plugins will also increase the start up time.
This is a good point.
Moreover, as far as I understand, mercurials provides less strict backward compatibility and stability for the plugins than for the core.
Well, this seems a bit strange argument. All the stuff comes from the mercurial tarball itself, and most of them is even installed as default. If it's really unstable and not recommended to use, they should stop shipping and installing craps in a single tarball. So, an ideal solution is to separate "core" and "others". This should be done in both the tarball level and in the packaging level. Frankly, I'm not sure (rather skeptical) that "disabling *all* extesions" is good overall. A practical solution would be "disabling some rare/uncommon extensions"... Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User alpar@cs.elte.hu added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c4
--- Comment #4 from Alpar Juttner
OTOH, I've got already bug reports several times that some extensions were disabled as default.
You can simply categorize these reports as invalid. There is not a single line in the documentation of mercurial indicating that mercurial should work in this way. Instead, you can read in the documentation of _each_ extension that if you want to use it you must switch it on.
I'd be annoyed if I would have to change my hgrc at each time I install on new systems just for basic extensions like mq.
Well, that's your opinion. As far as I'm concerned, I'm much more annoyed seeing that mercurial works differently on different distros due to the different view of the packagers on what plugins are important enough to be loaded by default. I would like to keep this decision to myself. Also, it very easy to copy a .hgrc file from one home directory to another. The important point is that a feature of the mercurial (in the official release) is implemented as an extension because the developers think that feature should be optional. Otherwise they would put it into the core part.
Moreover, the change of command behavior can be seen even often for the hg core commands.
It is not true. Mat Mackall has very strictly been insisting on the backward compatibility since the first stable release.
Moreover, as far as I understand, mercurials provides less strict backward compatibility and stability for the plugins than for the core.
Well, this seems a bit strange argument. All the stuff comes from the mercurial tarball itself, and most of them is even installed as default. If it's really unstable and not recommended to use, they should stop shipping and installing craps in a single tarball.
By 'stability', I mean 'unchanging' here. For example, the 'imerge' extension (also turned on by default on openSuse 11.1) seems to be broken on the latest development version and it is likely to be removed from the next stable release. This could not happen with a core command. BTW. there is no bugfree software (except TeX :)) and the developpers' resources are also limited. It is natural that more attention is payed on the stability of the core features than the on optional ones.
So, an ideal solution is to separate "core" and "others". This should be done in both the tarball level and in the packaging level.
Frankly, I'm not sure (rather skeptical) that "disabling *all* extesions" is good overall.
I can just repeat myself. This is the only safe solution, and also it seems to be what the Mercurial developers assume when making design decisions.
A practical solution would be "disabling some rare/uncommon extensions"...
Probably not. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c5
--- Comment #5 from Takashi Iwai
OTOH, I've got already bug reports several times that some extensions were disabled as default.
You can simply categorize these reports as invalid. There is not a single line in the documentation of mercurial indicating that mercurial should work in this way. Instead, you can read in the documentation of _each_ extension that if you want to use it you must switch it on.
No, this is the comment from a developer's perspective. From user's perspective, installing a package mans that he/she can use that functionality as is. It's rather a question of usability.
The important point is that a feature of the mercurial (in the official release) is implemented as an extension because the developers think that feature should be optional. Otherwise they would put it into the core part.
But again the same question arises: if it's optional (and can be considered unsafe, as you mentioned below), why it is installed *as default* at all even without asking you?
Moreover, the change of command behavior can be seen even often for the hg core commands.
It is not true. Mat Mackall has very strictly been insisting on the backward compatibility since the first stable release.
Moreover, as far as I understand, mercurials provides less strict backward compatibility and stability for the plugins than for the core.
Well, this seems a bit strange argument. All the stuff comes from the mercurial tarball itself, and most of them is even installed as default. If it's really unstable and not recommended to use, they should stop shipping and installing craps in a single tarball.
By 'stability', I mean 'unchanging' here. For example, the 'imerge' extension (also turned on by default on openSuse 11.1) seems to be broken on the latest development version and it is likely to be removed from the next stable release. This could not happen with a core command.
Heh, "hg forget" is forgettable... :)
BTW. there is no bugfree software (except TeX :)) and the developpers' resources are also limited. It is natural that more attention is payed on the stability of the core features than the on optional ones.
Of course I know it very well as a developer, too. But, it's irrelevant with the topic -- whether we allow the features available as default or not.
So, an ideal solution is to separate "core" and "others". This should be done in both the tarball level and in the packaging level.
Frankly, I'm not sure (rather skeptical) that "disabling *all* extesions" is good overall.
I can just repeat myself. This is the only safe solution, and also it seems to be what the Mercurial developers assume when making design decisions.
Let me repeat, too: stop installing extensions from mercurial tarball "as default" if they are unsafe or unsupported. Regarding the packaging: my proposal is to split the packages into two (or more) parts, the core package and extension package(s). The extension packages can have own hgrc to enable it per installation. If this approach is acceptable, I'll work on it for 11.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User alpar@cs.elte.hu added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c6
--- Comment #6 from Alpar Juttner
Let me repeat, too: stop installing extensions from mercurial tarball "as default" if they are unsafe or unsupported.
It is a bit hard to argue if you twist my words in order to support your own agenda. If I'm saying it is "unsafe" to force everyone to use roller skates it does not mean that roller skates are "badly designed" or "buggy".
Regarding the packaging: my proposal is to split the packages into two (or more) parts, the core package and extension package(s). The extension packages can have own hgrc to enable it per installation.
This is a bad idea. - Firstly, it will not make anything better because if I want to use a certain extension, I must install the extension packages, then I will get a bunch of unwanted extensions turned on. It is especially a problem in multi user environments: if someone needs an extension at a point and ask the system admin to install it, then it will change the hg configuration of everyone. - Secondly, it will make things worse. Those extensions are that are shipped with mercurial are assumed _to be there_ (but turned off!!!) by default by all of the documentation, therefore so will do the users and third party tools. Even if you put every extension into a separate package, it will not solve the problems above: - In multiuser environment the extensions will be still either unavailable or turned on to everybody. - This would suggest that I should only have those extensions installed on my computer that I want to have to be turned on. But it means that I cannot change the config (e.g. turn on an extension temporally) when I'm offline. Anyway, I do not feel that it is easier to install (or remove) a package than to put a new line (or comment one line out) in the ~/.hgrc file. Especially, because - actually you cannot really use mercurial without having a custom config file (you must at least set your user name). - many extensions needs additional configuration in ~/.hgrc - enabling the needed extensions in ~/.hgrc before the use is what the documentation of mercurial itself and the documentation of each and every extension suggest.
If this approach is acceptable, I'll work on it for 11.2.
Please do not do that. The right solution is easy and is already in hand: simply do not hack the default global configuration of mercurial (i.e. do not switch the extensions on by default). As far as I heard, this is what the Debian packagers plan do, as well. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c7
Takashi Iwai
(In reply to comment #5)
Let me repeat, too: stop installing extensions from mercurial tarball "as default" if they are unsafe or unsupported.
It is a bit hard to argue if you twist my words in order to support your own agenda. If I'm saying it is "unsafe" to force everyone to use roller skates it does not mean that roller skates are "badly designed" or "buggy".
Well, this argument can't be applied straightforwadly to "why disable *all* extensions". Are all extensions are like roller-skates? Is your argument applied to, for example, mq extension? Why can't it be used by everyone as default? What really annoys me is the request to disable *all* extensions, not some extensions. The extensions are great, and majority of people do want a certain set of extensions always, such as mq. Just a small subset, but there are certainly "de facto standard" extensions. Honestly, I don't care any more about mercurial for the time being, so I'll likely follow your advice, disabling everything. But, it's a pretty discouraging way of change from the usability POV -- that's why I've tried to discuss... Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c8
Takashi Iwai
participants (1)
-
bugzilla_noreply@novell.com