On Thu, Aug 11, 2005 at 09:54:55AM -0700, [EMAIL PROTECTED] wrote: > Quoting David Roundy <[EMAIL PROTECTED]>: > > > No, working at a higher level won't address the postget "remote > > defaults" issue, what it will do is to make your run_posthook function > > unnecesary, which would mean that adding posthook support to a command > > will only require that the command add the posthook flag to its list of > > DarcsOptions, which seems like it would be nice, and the posthook would > > be guaranteed to always run on command success (i.e. if the command > > exits with ExitSuccess). It would mean that we'd have to be careful > > about when the darcs exits with ExitSuccess... i.e. the question of > > whether to exit successfully when there are no patches to pull/apply > > could become significant. > > Could we get around this question by adding a command line switch to > those commands so that people can specify in defaults what those should > return when there are no patches? We could default to exitting > unsuccessfully when there are no patches, and then let the user override > this. I think exiting unsuccessfully when there are no patches makes > sense because when the repo doesn't change, do you really need to run > your script, right? But at the same time, if you're logging darcs > activity you may want to record anything and everything. On the other > hand, returning the number of patches could be handy too; the problem > here is that we are no longer consistent with the rest of the unix tools. > Another solution here is to always run the hook even when there are no > patches and then pass the number of patches to the script possibly in the > env. The problem here is that we are offloading the complexity to the > scripts, but perhaps this is for the best since each user has a better > idea how they want to use darcs than we do.
Hmmm. I think of these options, I'd at least start out with the "passing the number of patches through the environment" scheme. This is a nice feature anyways, since the script might want to customize itself based on the number of patches. Then if that seems too burdensome, we could add a --no-patches-is-failure patch that causes darcs to exit with failure if there are no patches. But it seems best to start with the "helpful anyways" solution. One could also achieve a similar effect by passing the names of the patches through the environment, and if that is an empty string, you know there weren't any patches to be pulled. > > Actually, I'm thinking that if we implemented posthooks in this manner, > > we could avoid modifying the commands at all, and add the DarcsOption > > like we do the --help and --list-options flags in DarcsCommands itself. > > Then every command would support --posthook, and they'd all behave in > > the same way. > > > > The trick, by the way, would be to use (in consider_running) code > > something like > > > > do (command_command cmd) (FixFilePath fix_path:specops) extra > > `Control.Exception.catch` foo specops > > foo (ExitSuccess) specops > > where foo (ExitException ExitSuccess) opts = run_posthook opts > > foo e = Control.Exception.throwIO e > > > > which would mean that if the command either doesn't call exitWith (and > > just returns) or calls "exitWith ExitSuccess", the posthook will get > > run. > > I've been keeping myself busy with other projects lately, but this is a > good idea, maybe I can find time to implement it over the weekend. That would be great! I sometimes feel like a bit of a leech, sucking precious developer time out of other projects, or at least hoping to do so... -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
