Stefan Sperling <stsp_at_elego.de>:
> I would guess it handles missing copyfrom sources more intelligently
> than "svndumpfilter include", which simply errors out when it hits
> that case (svndumpfilter: E200003: Invalid copy source path '/foo').
Yes, it does. I have to admit this is a recent development -
following a recent bug report, repocutter removes copyfrom references
to expunged revisions, but that bug never came up when it was named
svncutter.
esr_at_snark:~/WWW/reposurgeon$ repocutter help
repocutter - stream surgery on SVN dump files
general usage: repocutter [-q] [-r SELECTION] SUBCOMMAND
In all commands, the -r (or --range) option limits the selection of revisions
over which an operation will be performed. A selection consists of
one or more comma-separated ranges. A range may consist of an integer
revision number or the special name HEAD for the head revision. Or it
may be a colon-separated pair of integers, or an integer followed by a
colon followed by HEAD.
Normally, each subcommand produces a progress spinner on standard
error; each turn means another revision has been filtered. The -q (or
--quiet) option suppresses this.
Type 'repocutter help <subcommand>' for help on a specific subcommand.
Available subcommands:
squash
select
propdel
propset
proprename
log
setlog
strip
expunge
pathrename
renumber
reduce
Basically, whenever I perceive a need for some kind of Subversion repo
transformation that isn't expressible in gitspace, I thow it in here.
Thus propdel/propset/properename, no prize for guessing what those do.
The strip/reduce operations, as previously noted, do test load reduction.
The important ones for dissecting multiproject repos are
expunge, pathrename, and occasionally select.
Some other operations can be done in reposurgeon but lived here before
reposurgeon existed; log and setlog report and set change comments, and
renumber does the obvious (usually to clean up after an expunge or select).
The squash operation is a bit of a mini-epic.
esr_at_snark:~/WWW/reposurgeon$ repocutter help squash
squash: usage: repocutter [-q] [-r SELECTION] [-m mapfile] [-f] [-c] squash
The 'squash' subcommand merges adjacent commits that have the same
author and log text and were made within 5 minutes of each other.
This can be helpful in cleaning up after migrations from file-oriented
revision control systems, or if a developer has been using a pre-2006
version of Emacs VC.
With the -m (or --mapfile) option, squash emits a map to the named
file showing how old revision numbers map into new ones.
With the -e (or --excise) option, the specified set of revisions in
unconditionally removed. The tool will exit with an error if an
excised remove is part of a clique eligible for squashing. Note that
repocutter does not perform any checks on whether the repository
history is afterwards valid; if you delete a node using this option,
you won't find out you have a problem until you attempt to load the
resulting dumpfile.
repocutter attempts to fix up references to Subversion revisions in log
entries so they will still be correct after squashing. It considers
anything that looks like the regular expression \br[0-9]+\b to be
a comment reference (this is the same format that Subversion uses
in log headers).
Every revision in the file after the first omitted one gets the property
'repocutter:original' set to the revision number it had before the
squash operation.
The option --f (or --flagrefs) causes repocutter to wrap its revision-reference
substitutions in curly braces ({}). By doing this, then grepping for 'r{'
in the output of 'repocutter log', you can check for false conversions.
The -c (or --compressmap) option changes the mapfile format to one
that is easier for human browsing, though less well suited for
interpretation by other programs.
Nowadays the analogous operation would probably be handled by a git
lift followed by a reposurgeon 'coalesce' command, but I've left this
in place in case people want to stay in Subversion. One of the few
places reposurgeon is still weak five years in is that its Subversion
export is not very good - doesn't round-trip losslessly with import
the way fast-import files do.
--
Eric S. Raymond
Received on 2016-02-03 14:07:15 CET