Re: Behavior check: svnadmin load of revisions with no datestamp

On Mon, 26 Feb 2007, Ben Collins-Sussman wrote:

> On 2/26/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>
> >But I think you misunderstood my question. I am taking for granted that
> >the
> >ability to have a missing svn:date is *not* a bug. My question is, "In
> >such
> >a case, should a date suddenly appear just because you dump and load the
> >repository data?" I think not. *That's* the bug I'm talking about.
>
> I think you've identified a bug, yeah.

Given that missing/incomprehensible dates are allowed in the
repository, this is certainly a bug, +1.

Can someone clue me in to why we allow this state in the first place?
Given the impact on Subversion operations which take dates as input, I
don't see the ability to unset the date on a revision as a valuable
enough benefit to allowing missing/incomprehensible dates into the
repository in the first place.

> In that same vein, what if a revision has no svn:author property?

I doubt this is a problem for any existing Subversion operations.
Commits to a mod_dav_svn-fronted repository which isn't configured to
issue a HTTP basic auth challenge never set a user name. This
behavior seems okay to me.

FWIW, it is possible to set a (default) user name via a hook script,
and/or block removal of the user name revprop, if you want to prevent
this situation

> That's far more common (and less havoc-wreaking) than the 'no
> svn:date' scenario. In that case, might 'svnadmin load' (or even
> 'svnsync sync') be accidentally creating svn:author properties?

Good question, Ben. Has anyone tried this already?