Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 26 Apr 2017 17:57:18 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: dev@subversion.apache.org
Subject: Re: 'svnadmin load-revprops' as first-level command?
Message-ID: <20170426175718.GA32483@fujitsu.shahaf.local2>
References: <20170425193618.GA18666@fujitsu.shahaf.local2>
 <727D8E16AE957149B447FE368139F2B5A8F5FB77@SERVER10>
 <CY1PR15MB07934EAED809775A26063FAAF0110@CY1PR15MB0793.namprd15.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CY1PR15MB07934EAED809775A26063FAAF0110@CY1PR15MB0793.namprd15.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
archived-at: Wed, 26 Apr 2017 17:57:31 -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@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