On Tue, Sep 09, 2008 at 12:33:46PM +0100, Eric Kow wrote: > So previously, we said > > Eric only considers code comments, documentation and test suite > modifications to be obvious > > I think this sort of change is something I'm willing to consider obvious > and start fast-tracking as well. Objections?
It's already applied and is being pushed, and I see no reason to short-circuit the normal testing framework for this sort of thing. Speaking of which, we really should get zooko (or can you do this?) to switch the buildbots over to darcs-unstable. Otherwise they can't give you much help, as you won't know until after you've applied a bad patch... > On Mon, Sep 08, 2008 at 23:41:05 -0700, Dmitry Kurochkin wrote: > > Tue Sep 9 10:24:29 MSD 2008 Dmitry Kurochkin <[EMAIL PROTECTED]> > > * Move network related options to network_options. > > > > Tue Sep 9 10:28:24 MSD 2008 Dmitry Kurochkin <[EMAIL PROTECTED]> > > * Space in Darcs.Arguments module. > > > > Tue Sep 9 10:37:43 MSD 2008 Dmitry Kurochkin <[EMAIL PROTECTED]> > > * Documentation for -[-no]-http-pipelining options. > > Move network related options to network_options. > ------------------------------------------------ > This looks good to me Yes indeed. > > -ssh_cm = DarcsMultipleChoiceOption > > - [DarcsNoArgOption [] ["no-ssh-cm"] NoSSHControlMaster > > - "don't use SSH ControlMaster feature [DEFAULT]", > > - DarcsNoArgOption [] ["ssh-cm"] SSHControlMaster > > - "use SSH ControlMaster feature"] > > +network_options :: [DarcsOption] > > +network_options = > > + [DarcsMultipleChoiceOption > > + [DarcsNoArgOption [] ["ssh-cm"] SSHControlMaster > > + "use SSH ControlMaster feature", > > + DarcsNoArgOption [] ["no-ssh-cm"] NoSSHControlMaster > > + "don't use SSH ControlMaster feature > > [DEFAULT]"], > > + DarcsMultipleChoiceOption > > + [DarcsNoArgOption [] ["http-pipelining"] HTTPPipelining "enable HTTP > > pipelining", > > + DarcsNoArgOption [] ["no-http-pipelining"] NoHTTPPipelining "disable > > HTTP pipelining"]] > > I would tack [DEFAULT] on one of these (or maybe that would be too messy > in the code since we have a different default depending on the libcurl > version) That'd be a good improvement, but as you say, it's a bit tricky. It should just involve some cpp work, but that work ought to be in URL.hs, not here, so it'd involve an extra export. > A sort of random note: do lazy repositories mean that we have to let > pretty every darcs command (e.g. apply, check) have networking options? > I recall having an apply hang on me once until I hacked up darcs apply > to accept --disable-pipelining (now --no-http-pipelining) Yeah, we might want to move network_options into the "all" category so that all commands automatically get it. Of course, the same arguments apply to the ssh_cm stuff, which is why it's good to have these two together. David _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
