Quoting David Roundy <[EMAIL PROTECTED]>: > On Tue, Aug 02, 2005 at 06:54:14AM -0400, David Roundy wrote: > > ... You shouldn't read defaults yourself, the code's already written that > > does that. If you want to use the *remote* defaults, that's another > > issue. But you shouldn't ever stick anything in defaults that isn't a > > valid flag. (Users could mistakenly do so, and we should be forgiving in > > parsing the file, but darcs shouldn't ask them to do so.) > > Sorry, I realized I was a bit abrupt there, and that you aren't an old > darcs coder. Defining new flags is done in DarcsArguments (there are many > examples there to follow), and then one imports the new flag into the > actual command. That's all that's needed to make defaults work with a > given flag (or to make it acceptable on the command line). Then one checks > for the new DarcsFlag constructor that was added to see whether the flag > was given (either on command line or in defaults), and to see what the flag > argument was (the hook itself, in this case).
It's nice to know I did it correctly. I inferred out how to add a local default by just following existing examples. But I was under the impression that to get the postget hook working we would need to read the per-repository defaults of the exising repo which is possibly remote. This is where I got stuck, the existing code for inspecting a default flag assumes two things, 1) the defaults can be read inside the ReadableDirectory monad which as near as I can tell assumes that the files are connected to the local file system, 2) that the defaults come from both the local repo and ~/.darcs/defaults. Both (1) & (2) make it difficult to reuse the existing code to fetch what I'm calling 'remote defaults'. I would like to finish implementing the posget hook since I've already come so far with it. With the code I have since sending in my first patch I could stop and have a local, user defined default for postget. BTW, I added the commandline switch --postget-command=COMMAND. But, I don't think postget is actually useful until it can read the remote defaults and use them. So I guess my email was asking for advice on how to change assumptions (1)&(2) so that implementing this will be acceptable. I could also just copy, paste, and edit the existing code, creating two copies of almost identical functionality that would then run the risk of diverging, but that's a last resort. That is the path I started down when I mimiced show_motd to fetch the remote defaults file. I don't think just adding a parameter for the specification of the remote repo's path will be enough, as it looks like ReadableDirectory needs a path which is local. Perhaps I'm wrong here? > Each darcs command specifies which flags it wants in its > command_darcsoptions, but doesn't necesarily need to do anything itself to > implement that command. Yes, and it's a nice frame work. When I initially added command line switches to the get command I was very impressed by how painless it was to add them. It was like using a simple template. > In this case, I'd implement it at a higher level, > in DarcsCommands.consider_running. Working at this higher level will let me use the defaults from the remote repository? I had not examined consider_running, perhaps I'll have to do that tonight. Thanks, Jason _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
