Ben Collins-Sussman <firstname.lastname@example.org> writes:
> > use #include apr_general, and then use strcasecmp().
> Yikes! I naively copied that function from other places in the same C
> file, being used for the same purpose.
> I better go fix them both! Thanks.
Oops -- sorry, didn't mean to take the wind out of your sails. I
remembered some of the history of this, from discussions with
cmpilato, and wanted the log message to reflect that.
> I wanted the function to return *three* states of the executable
> property: on, off, or non-existent. They correspond to the actions of
> "do a +x", "do a -x", or "do nothing".
> I could have returned the actual property value, but I thought it was
> simpler to either return NULL, or return an *allocated* TRUE or FALSE.
> You don't think that's simpler for a caller to parse? I did. Simpler
> than having a caller parse an svn_string_t value, I think.
What about an enum?
By the way, I have a UI design question:
Are there circumstances where it's useful to say "this should never be
executable"? That is, such a file would get `chmod -x' when you do an
update, if you had accidentally +x'd it.
At first, I was imagining that we'd have a single property,
"svn:executable", and if it were set at all, then Subversion would
keep that file executable. That is, after every checkout/update, svn
checks to see if the property is set, and if it is, it makes sure the
file is executable. Simple, idempotent, who could ask for more?
When the property gets removed, the receipt of that prop change would
turn off the file's executableness; but other than that, *absence* of
the property would not toggle the execute bit off on every update.
Instead, absence of the property would normally mean that Subversion
doesn't do anything with the execute bit.
(One immediate question with this plan, of course, is what value
should people set for the property? Handling boolean parameters in a
key/value universe is annoying :-). I guess it would be "yes" or "on"
Anyway. Then I saw the way you actually implemented it, and thought
to myself, "Hmmm, how interesting, Ben came up with a completely
different way!" And I can't see anything wrong with it. I'm just not
sure when one would want to force a file not-executable. I can see
wanting to enforce executablenss, and wanting to ignore
executableness, but not wanting to enforce *non*-executableness. :-)
FWIW, note that neither of these ways is the way described in the
issue. But that's okay, I think the initial plan in the issue was the
worst of the lot, heh.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 26 03:50:46 2002