>>>>> Colin Watson <[EMAIL PROTECTED]> writes:
>>> I think my scars from using GNU Arch are finally fading. If you
>>> haven't used bzr before, you should find it to have most of the
>>> benefits and few of the drawbacks; its designers were certainly
>>> very aware of both aspects of Arch.
>> One advantage of GNU Arch is that it allows one to make local
>> branches for remote projects without having to clone the whole
>> remote repository. AFAIK, it's the feature that most of the DVCS
>> are still lacking.
> git has shallow branches,
Though somewhat limited.
> and it's on the roadmap for bzr too, though not done yet.
> (I actually like having to clone the whole remote repository, though,
> because it effectively gives me an automatic backup. I have regretted
> the fact that Arch didn't give me this,
GNU Arch allows this either. You could use $ tla
archive-mirror, or just `rsync' the remote repository.
Since GNU Arch uses archive names rather than archive locations,
one could conveniently use one archive name for, e. g.,
different locations of its mirrors, as reachable from different
hosts. (E. g., I have a mirror of my home archive at work and
vice versa, and I use [EMAIL PROTECTED]' and
[EMAIL PROTECTED]' both at home and at work.)
> but unfortunately only years after the point where it would have been
> useful; a portion of dpkg's revision control history is lost,
> probably forever, due to this.)
Due to the repository wasn't backed up?
[...]
>>> I'm not sure what to do about the IX thing; an option called
>>> --warnings doesn't really seem to reflect the possibility of
>>> prepending some groff input which does some other stuff. Yet, I
>>> think the important thing here is that it should be easy for people
>>> to check their manual pages, and that the option we add should
>>> reflect that.
>>> How about an option called --audit (and perhaps something like
>>> --audit-warnings=mac,escape if you want finer control)?
>> Why not --audit and --warnings[=...]? The former given without the
>> latter will behave as if the latter is given without an optional
>> argument, while the latter given without the former will just switch
>> Groff warnings on, while not adding the `-maudit'.
> That produces strange semantics, though, IMO: --warnings would enable
> the checks themselves, and all that --audit would do in addition to
> --warnings would be to switch some particular warnings *off*, which
> isn't what "audit" means! I'd rather have --audit be the main switch
> (easy to use, simple to explain) and have something else to modify it
> for experts who want fine control.
It seems like we have some misunderstanding here. The cases I
suggest are as follows:
$ man --warnings[=WHICH] -- enable warnings, either a default
set, or as specified;
$ man --audit -- enable `-maudit', and a default set of
warnings;
$ man --audit --warnings -- completely the same;
$ man --audit --warnings=WHICH -- enable `-maudit', and a
specified set of warnings.
So, `--audit' doesn't switch any warnings off.
> It had also occurred to me that 'man -A' would be free as a short
> spelling of 'man --audit', although it would be worth checking the
> other GNU/Linux man implementation to make sure it doesn't clash with
> something there.
That's a minor issue. I'd expect that scripts would use
`--audit' (for `man' users not familiar with Debian `man-db' to
understand easily), and I don't feel that `man --audit' will be
used too frequently outside of scripts.
[...]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
