I guess what I'm afraid of is that the stubs are a premature
generalization. Many, many times in this project, we've laid out a
skeleton for where we thought we'd be going, only to discover along
the way that things weren't going to look like that after all.
Can you redo the patch to cover just the commands that are currently
implemented? I like the dispatch table idea, and the interface to
command functions seems good too. (Caveat: I don't feel that I have
enough experience in this area to make a solid judgement, so would be
interested to hear what some other people think of it.)
Also, it still leaves us free to use a standard option processor (or a
reimplementation of a standard option processor), since that's largely
unrelated to the command dispatch.
By the way, there's no need [afaik] to tar/uuencode/base64/etc your
patches. Just post a ChangeLog entry and patch, directly in the mail;
that's usually easier to look over.
Thanks,
-K
Bruce Korb <bkorb@cruzio.com> writes:
> Karl Fogel wrote:
> > Could you post a ChangeLog entry, or whatever, describing the change
> > in more detail? Specifically, is it necessary to have all these stub
> > files present from the start, even those that aren't being used, or
> > could we instead just add them as they're needed?
>
>
> The goal of the change is twofold:
> 1. Tabularize the command dispatch. This makes it possible to implement
> svn as a shell much more easily *AND* it makes each command a simple
> plug-in. One could even plausibly theorize about allowing a user
> to load a shared library with their own special-purpose commands.
>
> 2. Add in the commands we are pretty sure we want once.
> Each command is listed in five places:
>
> 1. The Makefile.am has an entry for the command procedure file
> 2. The command procedure file itself
> 3. The command procedure declaration
> 4. The command enumeration
> 5. The dispatch table entry
>
> and soon:)
>
> 6. The description of the applicable options for the command
>
> This is what one generally tries to avoid. I prefer to just have
> #2 and #6 and let some script drive all the glue pieces (#1, 3, 4 & 5).
> I made the assumption that there would be even more objection
> to this than to what I put forth today. If that is not true :-),
> I can easily make a glue script and dump the stubs. But still,
> the empty stubs give you a concrete view of the work we intend
> yet to do. A "better sense of progress" :-)
Received on Sat Oct 21 14:36:14 2006