>>>>> Colin Watson <[EMAIL PROTECTED]> writes: >>> 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. > Yes, I know it allows it, but it doesn't *give* you it as standard. Not sure whether having two choices instead of one is a good or a bad thing, but certainly, more freedom requires more responsibility and care. > It's impossible to have an un-backed-up bzr (or, for that matter, > git) repository as long as even a single person has made a branch of > it. So, I'll end up having some archives backed up on two hosts at home, and on three more hosts at work... Now that I've some experience with more DVCS', I've to admit that GNU Arch is more difficult to learn and use. However, its model still seems to me more developed than the models of the other DVCS (though all the models used in the DVCS' I know look similar to me), and seem to give user somewhat more flexibility and freedom. Could you suggest a place where it'd be more appropriate to discuss different VCS', than on the Debian BTS? [...] >>> 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. > There's no misunderstanding; I understood exactly what you were > proposing. [...] > Now, think about the difference between: > man --warnings=mac,escape > ... and: > man --warnings=mac,escape --audit > What does --audit do *in addition* to --warnings? Precisely one > thing: it adds this to the groff input stream: > .de IX > .. > The sole effect of that is to disable a warning! Indeed. > I think these semantics are bizarre and I would prefer to avoid > them. Increasingly, I think we'd be better off with --audit taking an > optional argument to specify the groff warnings to be enabled, rather > than trying to split this into two options. May you suggest a way for *enabling* a warning for `.IX'? We are not only to have work-arounds for specific generators' bugs, but to have some ways to catch these bugs as well. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]