On Tue, Aug 02, 2005 at 10:26:22AM -0700, [EMAIL PROTECTED] wrote: > 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. Yeah, that's not a bad idea (although too much verbosity can be annoying). We could always *also* do the "author" modification, which would give users one more exposure to defaults. > 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. Hmmm. No, the verbose option doesn't have that effect. I don't think I'd want to add it to --verbose itself, since often verbose is used for other reasons than debugging. But we could either support -vv (--verbose twice), which could have that effect, or we could add a separate --debug-flags command. I'd lean towards -vv, which is used in other programs, and avoids adding a separate flag. More --verbose means more verbosity! :) But yeah, notifying users where the flags come from would be very helpful. > > 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. The problem with passing a filename is that we'd have to decide on the format for that file, which isn't readily extensible. There are a disturbing number of bits of information that might be handy to pass to the users (names of patches, name of command being performed, arguments to command being performed, flags passed to command being performed, repository in which the command was run, what files were modified by the patches, hashes of the patches, actual content of the patches, etc), and the precise information passed will be different for different commands, but one would like a single hook script to work with multiple commands. e.g. one would like to be able to write a simple log script that logs every darcs command, which ideally would be as simple as something like (in defaults): ALL --post-hook "echo darcs $COMMAND @FLAGS @ARGS >> /path/to/log" Environment variables allow someone later to pass some new and interesting information to the post-hook without breaking older posthook scripts by changing the format of a temporary file, and without requiring that hook scripts parse a (possibly quite long) file containing this information. > > 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? The question is how we find the filenames. When performing a record --all, we never store the patch in memory--to do so would be prohibitively expensive in some cases. Finding out which files are modified in a record would either require tricky lazy annotation of which files are modified as we lazily create the patch and write it to file... but that would be a bit of a pain. So more likely we'd just read and lazily parse the file after we've written it in order to find out which files were modified, which would cost us one parsing of the file, which we'd like to avoid if we don't need the information. There may be similar issues (or potential issues) with other commands. > > 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. Right, that's the reason. Which leads to a secondary issue, which is that of requiring a prompting, because fetching remote defaults introduces security concerns. With other posthooks, we have neither of these considerations, which simplifies matters considerably. There's also the factor of finding out where to find the remote defaults. The "normal" defaults processing is all done before we enter the command, and therefore doesn't involve knowledge of where the remote repository is located. > > 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. Hmmm. Nice idea. The question is when defaults would be inherited. We need to allow the inherited prefs to be modified in existing repositories, which could be tricky. Perhaps (this would have to come *after* the support for "remote defaults") we could prompt the user if he'd like to accept a new inherited default if the remote version doesn't match his local default. That seems to me like a very nice solution (which also could raise user awareness of the defaults mechanism, which would also be a bonus...). It seems to me like this would be dependent on the remote defaults stuff needed for postget, so I'm thinking we can view it as a motivation to plough on through that (including the prompting stuff), with the idea that if we get it right, we can leverage that code to implement both the user interface and the repository-side interface for inherited defaults. :) (And this means that we'd be adding a --test-command, --boring-file command etc... which would presumably override the contents of _darcs/prefs/prefs and make that file obsolete.) -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
