[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svnadmin load-revprops' as first-level command?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 26 Apr 2017 17:57:18 +0000

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.schaber_at_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
Received on 2017-04-26 19:57:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.