[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: The next step in a table driven client

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-11-15 00:50:01 CET

Well, Ben offered me a ride home, so now I'm not rushing to catch a
train and can respond with content this time. :-)

> My proposal is to *not* do anything significant. :-)
> Instead, it is merely to isolate it so that experimentation
> becomes easy. Then, I will experiment a little bit and
> come up with a proposal. Whatever proposal would be something
> that specified the acceptable/required options to an
> option processing engine that would be driven by that
> something, rather than command name. The resulting state
> would get handed back to the implementation procedures in
> any of a myriad of ways.

Sounds like a good plan.

> For the time being, this is far and away the most trivial
> to implement and use for an experimental framework:
>
> typedef struct svn_cl__opt_state_t {
> svn_string_t *xml_file;
> svn_string_t *target;
> svn_string_t *ancestor_path;
> svn_boolean_t force;
> svn_cl__command cmd;
> const char *use_text;
> } svn_cl__opt_state_t;

Sure -- we can add stuff as necessary.

> a pointer to this struct gets added to the command descriptor.
> The option processing routine takes this ptr as an argument, instead
> of the addresses of each of the fields. It is trivial and gets me
> closer to where I want to go, even if the destination still has haze.

See what you mean, agree.

> > 3. Remaining arguments are files and dirs. Have a single function
> > that removes redundancies from this set (if you're recursing
> > into bar anyway, then mentioning bar/foo.c is pointless), and
> > passes it along to the command as the keys in a hash table.
>
> cute idea. Certainly not today, tho.

Yah. I'll write it within the next week, I'm pretty sure -- it's not
hard, it's something every command needs, and it'll make testing
easier. Don't worry about it for now.

> Probably because it is a baby step proposal and you are looking
> for a stride instead? :)

I think that's what was going on, yes. The step looks good, I doubt
we'd have to take any of it back. Go for it...

> Not a bit of that. The code will be essentially unchanged, except
> the main() routine will have access to the command code enumeration
> and will pass it to the arg processing routine, instead of the
> separate command procedures. This is a _very_ tiny step.

:-)

I understand the proposal totally, now, sorry if I was being dense.

+1. Seems winning to me,
-Karl
Received on Sat Oct 21 14:36:14 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.