"Perry E. Metzger" <email@example.com> writes:
> Thanks to someone who seemed excessviely interested in flaming me for
> wanting to get text dumps, it seems no one paid attention to the
> questions I was actually asking, so I'm going to ask them again...
Oh, I wouldn't assume that so-and-so's flame was the reason others
didn't answer your original question :-). More likely no one had a
good answer to give, so they didn't respond. That's a normal pattern,
and doesn't much correlate with the presence or absence of a flame in
> 1) Metadata:
> a) The fact that metadata is unversioned makes updates of log messages
> more dangerous than they need to be.
> b) The fact that metadata is unversioned means incremental dumps of
> the database, which are useful for all sorts of reasons, don't
> include updates to things like log messages.
> Therefore, there there any chance of revisiting the decision not to
> version metadata, or at least of finding a way of fixing b)?
There's certainly no chance of revisiting it for 1.0.0 or any of the
1.0.x series. Personally, I would also not want to revisit it for
1.1.x, since I think there are more important improvements to be made
> 2) AnonSVN:
> I can see to obvious ways to run a "shadow" AnonSVN server mirroring
> an original in near-real time:
> a) Do an incremental dump after every commit, and push it to the anon
> sever(s) where they get loaded -- only 1) gets in the way here.
I like (a), and for (1), you could have your post-revprop-change hook
write out a log of just the metadata changes -- make up some simple
XML format -- to be transported with the incremental dumpfile. (If
you do this, and you have time to package up the scripts in some
reasonably comprehensible way, we'd love to include them in the
contrib/ section of Subversion!)
And yes, I agree this is a kluge. It's just a question of priorities.
> b) Send over the db transaction logs and replay them, but I
> don't really know how to do this.
> Any advice available on this?
I think (a) is your best bet. I've never tried (b), but anyway a
method that keeps the data in human-readable/human-hackable form seems
somehow more appealing.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 19 17:03:43 2004