Quoting David Roundy <[EMAIL PROTECTED]>: > Perhaps even something as simple as making the message asking for author > name (when you first record in a new repository if you don't have EMAIL > defined)... we could place the user input in _darcs/prefs/defaults, and > instruct the user to edit it there if they change their mind?
darcs init and darcs get would alse be great times to remind the user. Perhaps: [Messages from init/get...] Per-repository defaults for darcs commands are stored in the file _darcs/prefs/defaults. See the darcs manual for more information [url to relevant section of the manual]. I think typically when people start using darcs, init and get are the first things they have to try. I wonder, do the verbose options tell the user when a default is being used from one of the defaults files? This could be an important thing to have in the future when people are trouble shooting odd darcs behavior. People don't see ~/.darcs and _darcs/prefs everyday so it's easy to forget about them and what might be stored there. > Yeah, potentially three post-hooks would be reasonable. We *could* omit > the -always and just require that the user specify the same hook for both > success and failure if they want an "always" hook. That's probably the best way to go initially, less work and complexity. > I'd pass information via environment variables. It's an easy-to-extend > mechanism that doesn't require that the hook know much. This could be > interested, since I wanted the hook code itself to be generic, but the > information you pass most certainly won't be generic. I *think* you can > define the environment variables in apply and they'll naturally be > inherited by the hook called outside apply, but this isn't something I have > much experience with. I don't like the idea of using environment variables (but maybe that's just me). Could we just do something similar to what is done with long comments? We could write the information to a file in temp (in the case here no test is defined) or the same directory where the test took place (giving it a random filename and all that jazz) and then pass the file name to the command in exec? I should add that I had assumed that when a test is run that the post apply hook would run from the same directory so that it could collect data left by the test if needed. We currently use CVS in a fashion like this, our test script writes out data about which tests passed and which failed. > In giving information like file lists, you'll have to be careful that you > don't mess up any laziness properties... and probably you'll want to check > the arguments for PostHook before doing any environment variable > definition, just to be a bit more efficient in the common case where > there's no post hook. Giving out filenames can cause a lot of extra patch parsing? > In case you're wondering why I want the post-hook code outside of Apply > (maybe it's already obvious...) the idea is that if we do it that way, the > only change needed to support a post-hook in a new command is to import the > post_hook DarcsOption and include it in our list of flags. Also, the > reason for making the flag name the same for all commands is so users can > define a generic post-hook if they like, with the ALL mechanism of > defaults. Ah, yes this seems like a good idea. > Yeah, postget would be a nice feature, but it's much harder than any other > sort of post-hook (even harder than a post-init!). So it makes sense to > wait a bit to see the design issues that come up in implementing the easier > post-hooks. I must be missing something. The only reason I can think of that would make the postget hook complicated is the fecting of remote defaults as per my other emails. > Defaults and "prefs/prefs" are very different objects... and I don't much > like the latter, although I don't know of a better way of implementing such > features. "prefs" is used for properties that need to be pulled from one > repository to another, which defaults is private. The trouble is that > users do need to be able to override prefs, which is why ideally we'd have > prefs be in two places. It would complicate the format of defaults, but it would almost be nice if there was an 'inherit' field we could give for the defaults. inherit get --postget-command="echo this is an example postget" Then have inherit be optional, if it's there then that line will be placed exactly how it is in any copy of the repository. Otherwise, the default stays where it is. I'm not sure how 'inherit' would be used in ~/.darcs/defaults, perhaps there it determines if 'darcs init' should copy that line to the per-repository settings. I think this sounds very reasonable, and hopefully isn't too confusing to people. What do you think? If we went with this approach we could stop using _darcs/prefs/prefs. We could replace darcs setprefs with darcs setrepoprefs and darcs setuserprefs that would give a nice way to modify things in _darcs/prefs/defaults and ~/.darcs/defaults respectively. Although, having those commands would be a low priority. Thanks, Jason _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
