subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric S. Raymond" <>
Subject Re: svncutter can be removed
Date Wed, 03 Feb 2016 13:07:06 GMT
Stefan Sperling <>:
> 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

    esr@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:

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@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.
		<a href="">Eric S. Raymond</a>

View raw message