On Mon, 26 Feb 2007, cmpilato@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2721
> Issue #|2721
> Summary|svn:date handling could (should?) be more robust
> Component|subversion
> Version|trunk
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|ENHANCEMENT
> Priority|P3
> Subcomponent|src
> Assigned to|issues@subversion
> Reported by|cmpilato
>
>
>
>
>
>
> ------- Additional comments from cmpilato@tigris.org Mon Feb 26 07:07:17 -0800 2007 -------
> Subversion allows users to tweak its revision datestamps by editing the svn:date
> property. As a result, users have the opportunity to change its value to
> something that uses a different-than-expected format (or maybe isn't a date at
> all). This today causes operations like 'svn log' to croak with a "Bogus date"
> error.
>
> But is that really necessary? Could Subversion simply recognize the date as
> bogus and mark it as such in the log output?
>
> ------------------------------------------------------------------------
> r2 | cmpilato | (invalid date) | 1 line
> Changed paths:
> M /file
> ...
Given the current state of affairs, Mike's suggestion makes sense to
me.
However, I don't think that we should allow invalid dates to enter a
Subversion repository in the first place. libsvn_fs should error out
if commit of such data is attempted. If libsvn_fs did this, the
current "Bogus date" error is a reasonable behavior.
- application/pgp-signature attachment: stored
Received on Mon Feb 26 22:04:35 2007