On Wed, Jan 07, 2004 at 09:14:05AM -0600, kfogel@collab.net wrote:
> "Erik Huelsmann" <e.huelsmann@gmx.net> writes:
> > > Today, getdate.y has not changed since we imported it
> > > into the repository back in August, 2001; no idea about its history within
> > > the old CVS repos.
> >
> > Which might be a symptom of:
> > 1) Extremely nice and foreseeing coding; or
>
> Some evidence for (1) is that we hardly ever get bug reports about the
> date parsing.
Well, considering that issue #408 is the oldest issue still around,
it's possible that they all went to complain and noticed that there
was already an open issue. I doubt it, though.
It's more likely that since we currently claim "our date parser works
just like CVS's" and most of our users are familiar with CVS's, they
just don't bother complaining.
>
> > 2) Extremely obfuscated code which nobody dares touching and everybody has
> > something better to do anyway.
>
> If there had ever been a serious bug, sure we would have touched the
> code, no matter how obfuscated, and maybe rewritten it earlier. The
> fact that we haven't done so is still evidence of (1).
Any threaded access to svn_opt_parse_revision() is a latent bug. Care
to audit svnup, subclipse, pysvn, svk, ...?
>
> I like Greg Stein's solution:
>
> A. Document a limited number of formats that we support, state
> explicitly that using anything else is "at your own risk", with
> results neither defined nor guaranteed to be supported in future
> releases.
I've written separately about the potential pitfalls with this approach.
> B. Revisit the rewrite issue in a more leisurely fashion after 1.0.
> MBK's patch doesn't have to be wasted. It's approximately a
> bajillion times cleaner and more comprehensible than the current
> code, and easier to extend. So, if we decide to splice it in
> after 1.0, all we have to do is make sure it supports all the
> *documented* formats from (A), plus any new ones we want to get
> from the upgrade, and then we're done. Obviously, we'll try not
> to deprecate formats unnecessarily, but it's not a disaster if
> suddenly "3" stops being a valid date. We don't need to treat
> the loss of some edge formats as an earth-shaking disaster --
> it's just something to do a cost/benefit analysis on, like
> anything else.
"last thursday" and "two weeks ago" are exactly the kinds of reasonable
formats that people will probably become accustomed to, and that we'll
probably want to deprecate.
> > What has been marked as a long lasting problem is the number of dependencies
> > to build Subversion. Removing getdate.* might relieve us from one of those
> > dependencies.
>
> How big is this burden, really? We hardly ever heard about it before
> this thread, which only started because of the upcoming 1.0 release.
>
So far, we have a limited number of non-developers building from source.
Most developers probably have bison installed already, or know how to do
so.
As an aside, as a developer, I take warning messages about conflicts in
the grammar at compile time as a sign of inattention to detail, and that
colored my first impression of svn.
>
> It would be painful to discover a subtle date parsing bug right after
> releasing 1.0. By dropping in a new parser now, we increase the
> chance of that by a *lot* (because the current code has had orders of
> magnitude more exposure than the proposed replacement).
>
Forget the parser; I can see bugs in the *lexer* on casual inspection!
We're just ignoring them, because they don't make the client crash, and
if svn log doesn't do what you expected you just try, try again, and
blame your own incompetence rather than the date-parser's.
"You're surprised? Congratulations, you've discovered a feature!
Amaze your friends with your new-found knowledge!"
Because we're not classifying the host of problems with the existing
parser as bugs, any replacement is guaranteed to be much more risky
than doing nothing at all.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 7 17:35:10 2004