On Mon, Aug 01, 2005 at 01:03:05AM -0700, Jason Dagit wrote: > Perhaps 'darcs send' should allow the user to add notes about the > patch bundle they are sending? I find my self wanting to do that...
$ cat /home/droundy/.darcs/defaults send --edit-description ... > Finally, the rationale for this feature is that now I can have a > "central" repository with a special test defined (one that sends out > email notification for successful patches), and I can use postget to > set a different test for the copies of the repository. So, when > someone gets a copy of the repo, the postget command will be run and > it will modify test so that it no longer sends out email notification. I'd rather support this feature with a hook to apply than with a hook to get. In spite of the fact that I created it, I don't care for the whole prefs and setprefs mechanism--it has too many potentially confusing features (see, for example, my response to your doc fix). I'd like most hooks (and get here is a special exception, since the repository in question doesn't exist until after the command is run) to be implemented as simple command-line flags that would normally be specified in either _darcs/prefs/defaults or ~/.darcs/defaults. Thus a post-hook in apply would quite naturally allow you to do your email notifications in the central repo. That said, I can imagine a few other uses of postget. One would be to fix permissions (or extended attributes, or anything like that). Another would be to to run autoconf or something as an aid to lazy or ignorant users. One could also use this as a chance to set up customized defaults... for example to set up the _darcs/prefs/defaults to run a permissions-fixing hook after each pull. Unless there's a compelling reason to the contrary, I'd prefer to make this not a prefs/prefs data object--precisely because setprefs *is* so confusing. The only reason to make it a setprefs object is if you need to make sure that the postget is *always* run, regardless of which repository is gotten from. I can see that several of the above scenarios would satisfy this criterion, but none of them seem like a particularly strong reason. -------------- Actually, as far as your reason for postget is concerned, I think we'd be better of fixing the bug of local gets, that they copy locally modified prefs. The reason they do that is because there's no way to tell whether the pref has been locally modified without parsing all the patches, which is something we'd really like to avoid (for efficiency reasons). I think the solution would be to split the prefs into two files, one for local (overriding) modifications, and one for the prefs set with setpref itself. Then we'd only copy the latter on a local darcs get. I'm envisioning something like: # contains the "gettable", "global" versions of prefs --not user-modifiable: _darcs/setprefs # where the user sets "local" versions of the prefs: _darcs/prefs/prefs We'd have to modify RepoPrefs to check in both locations. We'd be backwards-compatible, provided we echo the "global" prefs in _darcs/prefs/prefs, using the existing mechanism of modifying that file only if its current setting matches the "old" version in a setpref patch. I think this is two cleaner solutions to your problem (either a post-hook on apply, or fixing the local get prefs bug). The latter is a good idea anyways, since it makes local gets behave like remote gets. It also could allow us to make optimize --checkpoint somewhat more efficient, since we could trust that _darcs/setprefs (or _darcs/global_prefs?) hasn't been user modified, so we wouldn't have to search through the entire history looking for setpref patches. -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
