Greg Stein wrote:
> On Mon, Jul 13, 2009 at 17:13, Julian Foad<julianfoad_at_btopenworld.com> wrote:
>> ...
>> It could well be that --ignore-externals is the most commonly used by
>> far, in which case we might want to add a short alias for it. But before
>> we jump to any conclusions, we should also ask (the original poster, and
>> ourselves) whether the problem would be better solved in a different
>> way, perhaps by making "ignore-externals" a configurable option in
>> ~/subversion/config and having an inverse option (--with-externals ?)
>> available to override it if it only rarely needs to be overridden.
>
> Ugh. What if I set my config options different from yours? Will my svn
> behave in a subtle and hard-to-understand different way from yours?
Well, either way, it makes troubleshooting user issues a little bit
more difficult when it comes to environment options or config variable
options.
The following are my $0.02 thoughts. I don't pretend to know
everything here so I will most likely err in terms of coding and theory;
but, this gives me a good opportunity to learn the ropes.
I would think that it'd be simple (it actually is) to do a short option
for --ignore-externals. But that would limit the potential to expand
the option set. Say, a more important option than --ignore-externals
is created. Then obviously the short option (say -i) that was assigned
to --ignore-externals is removed and reassigned to the new important
option. That would break a few scripts that depend on -i being equal
to --ignore-externals. Then what happens to --ignore-externals? Should
a short option be assigned to it to replace the removed one? Either
yes or no will bring us to the same spot; what new short option should
we use(for yes) or wouldn't the no decision have invalidated this issue?
(thus having wasted whoever's time in creating the short option for
--ignore-externals). ["wasted whoever's time" is a term I'm not
particularly fond of, but for lack of a better phrase, that's the
only one I can think of. In actual fact, it wouldn't be a waste
of time. Just a learning experience.]
A 'better' way would be to increase it to a multi-character option,
i.e. -cl. But that will break the whole option set type,
apr_getopt_option_t as confirmed by Peter Samuelson. This would,
as I felt before, require recoding apr_getopt_option_t to use
char *opt, rather than the current 'int optch' in apr_getopt.h.
Or better yet, copy the struct apr_getopt_option_t and extend it
with a 'longer opt', i.e. const char * optstr. Then whatever
accesses the old structure will need to be changed to access
the new one. The outcome of this? A better option-set structure
that can increase the option playground (so to speak). So
--ignore-externals can be -ie. --ignore-something-else can be
-ise. Of course, a policy should be set to allow a decent set
of options to be created instead of assigning short-options to
every option available. So in the short run, with the multi-char
option, some/alot of code will need to be fixed. Long run?
A larger option field. Heck, even if we limit it to just
two characters, that's 26*26 possible options plus the punctation
ones, i.e. -?. Of course, some combinations would make no sense
and probably can decrease that possible list to a manageable
size. Of course, fixing the # of characters to 2 is arbitrary.
I could've said 3 or 4, but when does a short-option become
a long option? It would be silly to put -hlp to represent
help (when -? or -h would've sufficed); again, as stated,
some combinations make no sense/or are silly.
I believe there is a potential gain if the short option was
changed from (int) to (char *) (but limited to 2 characters).
Priority wise, I know it's not up there. It's an aesthetic
issue that shortens operators' typing; that's all (AFAIK).
But again, I might be short-sighted in terms of feasibility
and Subversion theory.
Corrections greatly appreciated.
Edmund
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2371206
Received on 2009-07-14 12:28:26 CEST