Quoting David Roundy <[EMAIL PROTECTED]>: > $ cat /home/droundy/.darcs/defaults > send --edit-description
I will certainly try this. Thanks for the tip. > ... > > 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. I've been using darcs for a while now and somehow completely missed defaults. I just checked with the documentation, and this looks like the right place. And I agree that a post-hook in apply is cleaner if we use defaults. At least for my target usage. How should a post-hook in apply interact with test? I guess you make the assumption that by the time you get to the post-hook that the test has suceeded? Perhaps it's best to have three hooks: post-apply-test-success, post-apply-test-fail, post-apply-always. In may situation I would only want/need post-apply-test-success. The next question on my list, is how do you pass context to the the command? Since I want to use it for email notifications, it would be nice to have the patch summaries and a list of files modified sent in the email. > 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. Your last sentence is exactly how I had planned on using it. I'm not sure how effective a postget command would be for fixing permissions. It would work for the first 'get', but subsequent pulls would not run the script and so newly added files would not have the 'fixed' permissions. At this point I'm realizing two things 1) Post apply hooks would be better for me 2) This is a nice feature and we should still have it. > 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. I don't care how the setting is stored, as long as postget is given a *chance* to run. Since the user can override postget with commandline switches I think it makes sense that the postget command be stored in defaults[*], and then the per user defaults can help control of this is run. [*] The one caveat here is that if someone fork/branch a project and they get a copy of the repository, and then start sharing it, the postget command will not be present in their branch. This could be really confusing, or it could be exactly what most people want. In the case of using a postget command to fix permissions then the new copy would surely want to have the same postget command. But, I'm really not sure without seeing how people respond to the feature. I think that putting it in defaults sounds like a good idea until we find out otherwise. I just realized that if needed, a postget command could install itself into _darcs/prefs/defaults. So there is not really a *need* for postget to be stored in prefs. > -------------- > > 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 I don't like the naming scheme, it doesn't help me to realize that one of them is not user modifiable. BTW, how will you make sure people don't modify it? mark it read-only and assume they behave? I'm also not sure if having two places with your settings is worth the confusion to the user. Given the current set of prefs, what would be in each? I think using defaults to store the overriding values would be cleaner. Otherwise, it may appear to the user that their prefs are stored in 3 files without a clear reason as to what should be where. Perhaps I'm missing something? > 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. Sounds like the post-hook in apply should be implemented, and something needs to be done with _darcs/prefs/prefs, but I'm not sold on the idea you present here. I also think that this postget hook is still a good idea, given the modifications to where the settings are stored that we talked about above in the first half the email. Thanks, Jason _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
