[ snip ]
> 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
2) Extremely obfuscated code which nobody dares touching and everybody has
something better to do anyway.
> 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...
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.
> Against that
> stability, we're talking about introducing new, untried code with some
> number of potential issues.
True.
[ snip ]
> The final point kind of balances itself out: this code doesn't get used or
> exercised that much, so there isn't a lot of need to "fix" it. But by the
> same token, that also means that introducing problems here will have a
> very low impact.
And since the new date parser takes away *a lot* of functionality, we might
as well risk it. And make sure users don't get used to using it anyway. (even
without it being officially supported as you suggest below)
> I worry that even if each of these things were addressed, then at that
> point, we'll be even further down the road where the risk/benefit tradeoff
> is even more weighed against changes.
Which - by your own argument above - are to be considered slim, since
Subversion addresses it's changes across entire trees with a single ID: the
revnumber.
> I believe the proper resolution is to recognize that the date formats are
> just another "contract" (to borrow ghudson's terms w.r.t APIs). SVN will
> make certain guarantees about specific forms of input. Pass something else
> at your own risk. If you depend upon behavior outside of the contract,
> then too bad if we need to alter code. We do this in many areas of the
> code. Where we find implicit contracts, then we try to document those to
> make them explicit. I'd like to posit that we're in the exact same
> situation here. Our cmdline client has got a lot of implicit behaviors
> that we try to document, and I believe that the acceptable formats are
> simply one of those situations.
By the time we want to replace the old code with the currently new code,
people will want to keep their old formats: no way it's going to go if we allow
it now.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 7 15:48:54 2004