Bert Huijben wrote on Wed, Apr 26, 2017 at 13:03:46 +0000:
> Perhaps the revprop load operation was designed to support some kind
> of 'refresh' of the revprops after an earlier dump/sync. In that case
> it might make sense to have a specific operation, as that would really
> change the operation to something completely else.
Ah, yes, that's exactly how it works: 'load-revprops' changes
already-committed revisions, whereas 'load' would commit new ones.
I agree that this difference warrants a separate subcommand for
'load-revprops'.
Is the help text clear?
{"load-revprops", subcommand_load_revprops, {0}, N_
("usage: svnadmin load-revprops REPOS_PATH\n\n"
"Read a 'dumpfile'-formatted stream from stdin, setting the revision\n"
"properties in the repository's filesystem. Revisions not found in the\n"
"repository will cause an error. Progress feedback is sent to stdout.\n"
"If --revision is specified, limit the loaded revisions to only those\n"
"in the dump stream whose revision numbers match the specified range.\n"),
Markus Schaber <m.scha...@codesys.com>:
> I guess that, especially for the "dump" case, "dump-revprops" is (or should
> be)
> much more efficient than a "dump" piped through "svndumpfilter". For "load",
> the additional overhead will be smaller, but still there. So I think this
> functionality should be implemented in svnadmin itself.
Agreed about efficiency of dump-revprops: as an svnadmin command, it
won't need to combine and generate deltas.
The remaining question is whether 'dump-revprops' should remain
a top-level command or become an option under the 'dump' command.
I can't say I feel strongly about this...
Cheers,
Daniel
