On Mon, 26 Feb 2007, Ben Collins-Sussman wrote:
> On 2/26/07, C. Michael Pilato <firstname.lastname@example.org> wrote:
> >But I think you misunderstood my question. I am taking for granted that
> >ability to have a missing svn:date is *not* a bug. My question is, "In
> >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
> 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?
Received on Tue Feb 27 01:30:49 2007
- application/pgp-signature attachment: stored