[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: date parser

From: Erik Huelsmann <e.huelsmann_at_gmx.net>
Date: 2004-01-07 15:48:18 CET

[ 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

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

> Against that
> stability, we're talking about introducing new, untried code with some
> number of potential issues.
[ 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

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.