Julian Foad wrote on Thu, 21 Jan 2021 15:59 +00:00: > I can't remember if there is a strong reason why version 2 is not > implemented in svnrdump. I have a feeling there is at least a > non-trivial reason. I looked some time in the past and it wasn't simply > a matter of adding a switch. As far as I recall, the reason was > basically that producing the full text of each changed file would > involve either complexity (caching on the local side) or inefficiency > (fetching the full texts over the network for each change instead of > recreating them from deltas),
«svnrdump dump» is implemented as a consumer of svn_ra_replay*(). That API gives deltas. The "caching" approach would amount to piping the stream to a «svnadmin load /path/to/ramdisk/$REPOS» and then running a plain old «svnadmin dump», wouldn't it? > and there has not been a strong need to support v2. > > Therefore: please add an option to svnrdump in Version 2 format. > > It makes me twitchy that there's any possible future in which that > > format might be unsuppoted or inaccessible. We _are_ committed to providing an upgrade path from 1.x to 2.x, you know. Always have been. You can stop twitching. Also, there's a non-negligible chance that your user got an error about format numbers because they ran «svnadmin load $REPOS_DIR/db», not because of anything to do with v3. That'd be a pilot error on their part. (We already have a milestone=2.0 issue to prevent this on our end.) > > Should I file an issue about this? > > You can certainly file an issue if there isn't one. (I can't see one in > a quick search.) Be aware that there don't seem to be developers around > volunteering for this sort of work at the moment. (I'm available for > hire.) What would a fix to that issue look like? > If I were to have a say I would recommend anyone should rather > work on adding v3 to reposurgeon and addressing any documentation that > may be lacking. +1
