On Mon, 26 Feb 2007, C. Michael Pilato wrote:
> Daniel Rall wrote:
> > On Mon, 26 Feb 2007, C. Michael Pilato wrote:
> >
> >> It appears that today if you 'svnadmin load' a dumpfile that contains
> >> revision with no svn:date property, the resulting repository will, for those
> >> revisions, have that property (set to the time of the commit of the loaded
> >> revision).
> >>
> >> I can't decide if this is a feature or a bug, but I lean toward the latter.
> >
> > IMO, this is definitely a bug, since it will result in a repository
> > with revision dates and numbers out of sequence, which impacts the
> > behavior of some operations which take a date or date range argument
> > (e.g. 'svn log -r {START_DATE}:{END_DATE}').
> >
> > Subversion expects "svn:date" to be set -- it doesn't consider an
> > empty date to be valid data.
>
> Unfortunately, that's entirely untrue. You simply can't make use of
> date-based lookups if the dates aren't present.
Uhh Mike, you just filed a bug yourself (#2721) about 'log -r {DATE}'
on an invalid date returning an error. "Entirely untrue" is
inaccurrate and a bit harsh, don't'cha think?
If we want Subversion to fully support invalid/missing dates -- which
I don't -- it's going to require some work.
> And even if they *are*
> present, that's not to say they are in a meaningful order. For example, if
> you use cvs2svn to load projects one-at-a-time into a Subversion repository,
> the dates will be completely screwy and overlapping.
...
Yup, this is what happened to the ASF's repository. It's *very* annoying.
- application/pgp-signature attachment: stored
Received on Tue Feb 27 01:21:47 2007