[PATCH] plan9: initial support for plan 9 from bell labs

[Steven Stallion]

On Sat, Apr 7, 2012 at 10:36 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Fri, 2012-04-06 at 14:42 -0700, Steven Stallion wrote:
>> +idiff(1) may be used to resolve merge conflicts, however it is not
>> +enabled by default. Users should use the following configuration snippet
>> +to enable this behavior:
>> +
>> +  [ui]
>> +  merge = idiff
>
> This is the old way of configuring merge tools. You should probably add
> an idiff entry to the generic mergetools/config.hgrc.

Will do.

>> +Some work remains with regard to documentation. Section 5 manual page
>> +references for hgignore and hgrc need to be re-numbered to section 6 (file
>> +formats) and a new man page writer should be written to support the
>> +Plan 9 man macro set. Until these issues can be resolved, manual pages
>> +are elided from the installation.
>
> The manpages are mostly an after-thought at this point, given that
> they're auto-generated from the built-in help.

That was my feeling as well. I'd like to eventually get to this for
the sake of completeness, but it certainly doesn't hinder the user.

>> /plan9/hgdiff
>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> +++ b/contrib/plan9/hgdiff    Fri Apr 06 14:39:47 2012 -0700
>
> Seems like this name should have a 9 in it.

Sure thing. hg9diff?

>> diff -r 329887a7074c -r 70fcfb0bf1f6 hgext/factotum.py
>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> +++ b/hgext/factotum.py       Fri Apr 06 14:39:47 2012 -0700
>> @@ -0,0 +1,119 @@
>> +# factotum.py - Plan 9 factotum integration for Mercurial
>
> Various people have made idle threats to integrate a generic keyring
> manager into the core:
>
>  http://mercurial.selenic.com/wiki/KeyringExtension
>
> It'd be nice if you could peek at that and articulate a plan for how
> factotum will work if and when that actually happens.

When the factotum extension was originally written a little over a
year ago this was exactly how I started. Unfortunately due to how
keyring is currently written, some of the information I needed to
flesh out the key information was missing. I would have to go back and
look for the details, but I believe it centered around the authuri. At
the time I didn't want to modify an unbundled extension; the plan was
to have something that could ship as part of the distribution.

>> diff -r 329887a7074c -r 70fcfb0bf1f6 mercurial/help/config.txt
>> --- a/mercurial/help/config.txt       Fri Apr 06 15:18:14 2012 -0500
>> +++ b/mercurial/help/config.txt       Fri Apr 06 14:39:47 2012 -0700
>> @@ -28,16 +28,17 @@
>>  paths are given below, settings from earlier paths override later
>>  ones.
>>
>> -| (Unix, Windows) ``<repo>/.hg/hgrc``
>> +| (Plan 9, Unix, Windows) ``<repo>/.hg/hgrc``
>
> That should probably say 'all' instead. Not sure if people are still
> using the VMS or BeOS ports...

Sure thing.

>>      Per-repository configuration options that only apply in a
>>      particular repository. This file is not version-controlled, and
>>      will not get transferred during a "clone" operation. Options in
>>      this file override options in all other configuration files. On
>> -    Unix, most of this file will be ignored if it doesn't belong to a
>> -    trusted user or to a trusted group. See the documentation for the
>> -    ``[trusted]`` section below for more details.
>> +    Plan 9 and Unix, most of this file will be ignored if it doesn't
>> +    belong to a trusted user or to a trusted group. See the documentation
>> +    for the ``[trusted]`` section below for more details.
>>
>> +| (Plan 9) ``$home/lib/hgrc``
>>  | (Unix) ``$HOME/.hgrc``
>>  | (Windows) ``%USERPROFILE%\.hgrc``
>>  | (Windows) ``%USERPROFILE%\Mercurial.ini``
>
> This will probably double the number of people in the world who've heard
> of Plan 9.

Fair enough :)

If you think updating the documentation isn't worth it, or worse
simply adding noise, I can definitely leave it out.

Cheers,

Steve