Greg Stein <gstein@lyra.org> writes:
> It would be clearer if those two if-blocks were combined. As it is, a reader
> has to look harder to realize that they are the same. Combining reduces
> their effort.
Indeed -- if this reader had looked harder, he would have seen that!
Thanks!
> >...
> > @@ -344,6 +353,10 @@
> > struct dir_baton *db = parent_baton;
> > if (svn_wc_is_normal_prop (name))
> > db->prop_changed = TRUE;
> > +
> > + if (svn_wc_is_normal_prop (name))
> > + db->edit_baton->received_some_change = TRUE;
> > +
> > return SVN_NO_ERROR;
>
> Same.
Check, same for the next
> > @@ -390,6 +409,7 @@
> > eb->target_revision = SVN_INVALID_REVNUM;
> > eb->is_checkout = is_checkout;
> > eb->suppress_final_line = suppress_final_line;
> > + eb->received_some_change = FALSE;
>
> FALSE is the default already, because of the apr_pcalloc()
Good point.
> > - rm = re.compile ('^(..)(.)(.) . [^0-9]+(\d+|-)(.{23})(.+)')
> > + # Try http://www.wordsmith.org/anagram/anagram.cgi?anagram=ACDRMGU
> > + rm = re.compile ('^([MACDRUG_ ][MACDRUG_ ])(.)(.) . [^0-9]+(\d+|-)(.{23})(.+)')
>
> Ha. I told you guys we wanted different column-0 characters.
:-)
No, seriously, the current way is better, I think.
Our goal is to have output that is human-readable and automatically
parseable. The latter is a formal, yes-or-no condition, and we still
meet it. There is no requirement that parsing be completely trivial
to implement, especially not if it means sacrificing human
readability.
If we start reserving column zero characters in lieu of good regexps,
we effectively make it impossible to start any prose sentence in
column zero, even though that's the natural place for sentences to
start.
There will always be compromises like this, as long we're trying to
meet two slightly incompatible goals for the output. We should
usually resolve these conflicts in favor of the humans, IMHO, except
when it would put a truly unreasonable burden on the parser (which
isn't even close to happening here).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 7 20:11:40 2002