"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.
> 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).
> > During that whole time, I don't recall any "big"
> > problems that people have actually experienced. It seems the largest issue
> > is missing the ISO formats, rather than a defect, per se.
>
> The ISO date formats might be considered a defect in the code, since it is
> too hard to add them to the current code without overseeing all the
> consequences...
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.
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.
> 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.
> > Against that
> > stability, we're talking about introducing new, untried code with some
> > number of potential issues.
>
> True.
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).
-Karl
---------------------------------------------------------------------
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:08:04 2004