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 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.
> In that same vein, what if a revision has no svn:author property?
> 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?
No, a missing author is fine because the filesystem code doesn't assume
there is an author for every commit. I'm sure that svn:date is a special
case here because that property is the one property that Subversion creates
itself at txn-start time, and rewrites itself at txn-commit time.
I haven't tested this, but I suspect the patch is as simple as the following:
--- subversion/libsvn_repos/load.c (revision 23433)
+++ subversion/libsvn_repos/load.c (working copy)
@@ -1219,11 +1219,13 @@
/* Grrr, svn_fs_commit_txn rewrites the datestamp property to the
current clock-time. We don't want that, we want to preserve
- history exactly. Good thing revision props aren't versioned! */
- if (rb->datestamp)
- SVN_ERR(svn_fs_change_rev_prop(pb->fs, *new_rev,
- SVN_PROP_REVISION_DATE, rb->datestamp,
+ history exactly. Good thing revision props aren't versioned!
+ Note that if rb->datestamp is NULL, that's fine -- if the dump
+ data doesn't carry a datestamp, we want to preserve that fact in
+ the load. */
+ SVN_ERR(svn_fs_change_rev_prop(pb->fs, *new_rev,
+ SVN_PROP_REVISION_DATE, rb->datestamp,
if (*new_rev == rb->rev)
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Feb 27 16:12:50 2007