RSVNDUMP(1)

📦
version 0.6.1 · 2 versions
, in fedora 43

💖 RSVNDUMP(1) 💖

okay bestie, sit down, hydrate, and let me tell you about rsvndump — she's a User commands girlie and she's about to dump a whole remote Subversion repo for you without you ever touching the actual repo data. iconic behaviour, honestly. 🦋

✨ NAME ✨

rsvndump — dumps a remote Subversion repository. yes that's it. that's the whole job. she does one thing and she slays at it. 💅

🌸 SYNOPSIS 🌸

rsvndump [options] url

that's the whole vibe. options, then the url. periodt.

🎀 DESCRIPTION 🎀

so rsvndump dumps a Subversion repository without having actual access to the repository data — which is exactly the access that the svnadmin(1) dump command normally needs. she's doing it remotely, she's doing it from the outside, she's not like other dump tools. 👑

If you invoke her with valid options, rsvndump will print a dump file to stdout, and optional progress to stderr. two separate streams, no crossover, we love a clean separation of concerns.

And because rsvndump can also dump sub-directories of a repository, the revision numbers in the dump don't necessarily reflect the original revision numbers. more on that in the REVISION NUMBERS section, bestie, don't skip it, it's important, I'm not even joking.

There are also some extra differences from a "normal" dump generated by svnadmin(1), and those are all listed out in DIFFERENCES TO SVNADMIN DUMP. go look. i'll wait. 💜

✨ OPTIONS ✨

Most of these options can also be found in svnadmin(1) and svn(1), and they should be semantically equivalent — unless stated otherwise. so if you already know those, you're kinda already fluent. still, let's go through them all, no skipping. 🙈

  • -h, --help — prints a nice help screen. it's nice. she said so herself.
  • -q, --quiet — don't print any progress. silence. peace. no thoughts head empty. 😌
  • -v, --verbose — print detailed progress, similar to svnadmin(1) load. can be specified multiple times — stack it up, girl, go feral.
  • -u, --username username — user name for repository authentication.
  • -p, --password password — password for repository authentication.
  • -r, --revision X or X:Y — specify the revision (or revision range) that should be dumped. X and Y can either be a number or "HEAD". the default revision range is "0:HEAD", i.e. the complete revision history.

Now, in contrast to svnadmin(1), dumps generated using this option can always be loaded into a new repository (unless --incremental is given, of course 🙃). However, the resulting dump may not exactly represent the original history. please take a look at DIFFERENCES TO SVNADMIN DUMP for further information. I'm begging you.

  • --deltas — use text deltas instead of full texts in dump output. smaller, cuter, delta-fied.
  • --incremental — create incremental output, suitable for concatenation. this results in a dump that does not contain a dumpfile header and no full base revision if the revision range does not start at 0.
  • --no-auth-cache — don't cache the authentication tokens provided by the user, e.g. user name and password, or manual SSL certificate validation. this is equal to the corresponding option in svn(1). no crumbs left behind. 🍓
  • --non-interactive — instead of prompting, the program will exit with an error. this is equal to the corresponding option in svn(1). she's not asking, she's leaving. 💀
  • --config-dir dir — use the given Subversion configuration directory when opening a session to the repository. this is equal to the corresponding option in svn(1).
  • --prefix prefix — prepend a given prefix to every node which is dumped. the first revision dumped will also contain the paths necessary to create the prefix.
Please note that it is assumed that prefix is really just a prefix string, with directories separated by "/". Therefore you need to append a "/" at the end of the string to make it a directory. For example, a prefix of myrepo/old_ might result in the following layout:
myrepo
 |- old_branches
 |- old_tags
 |- old_trunk

see how old_ is glued onto the front of everything? yeah. that's the bit. 🫶

  • --keep-revnums — keep the revision numbers in the output in sync with the repository. this is done by inserting empty revisions for padding if necessary.
  • --no-incremental-header — don't print the dumpfile header if --incremental is given and the revision range is not "0:X". this is useful if you really want to append an incremental dump to an existing file.
  • -n, --dry-run — don't fetch text deltas, resulting in a dump without file contents. this is mainly used for debugging purposes, as the program operates normally but runs much faster. no cap, it's zooming. 🔥
  • --obfuscate — replaces all file and directory names with random strings. this is useful for bug reports in combination with --dry-run. privacy era. 🧚

🌈 REVISION NUMBERS 🌈

The revision numbers in the dump output depend on the options and the path that are given to rsvndump. If you are dumping the root of a repository, you don't need to worry about revision numbers out of sync, of course — everything lines up, chef's kiss. 😘

If you are dumping a sub-directory, only the revisions that changed this sub-directory will occur in the dump output. The revision numbers in the dump are strictly sequential, so they will differ from the original ones. it's giving "renumbered and rebranded".

If you need to keep the revision numbers from the original repository (e.g. if a bug tracker depends on them 👀), you can use the --keep-revnums flag. It pads revisions that did not change the sub-directory with empty revisions. They don't have an author or date property, but they contain the log message:

"This is an empty revision for padding."

filler episode, but make it functional. 💅

💜 DIFFERENCES TO SVNADMIN DUMP 💜

The output generated by rsvndump may differ from the one generated by svnadmin(1) because rsvndump may handle file or directory copies differently than svnadmin(1). The latter does not support dumping of sub-directories within a repository out of the box. Instead, the svndumpfilter(1) tool will do this job. However, sometimes sub-directories cannot be filtered exclusively with svndumpfilter(1) because they have been copied from another place. rude, honestly. 😭

Since rsvndump has been designed to allow dumps of sub-directories even if your repository access is limited to this sub-directory, it will not access sub-directories other than the one you want to dump. Example given, dumping a branch will most likely not result in the full history of the branch, as it might have been copied from trunk at some point in time. so she stays in her lane. respectful queen.

Thus, rsvndump will generally replace a copy action by a simple add operation if both of the following conditions are true:

  • The source of the copy is outside the directory tree which is being dumped
  • The source of the copy is not included in the dump because the revision range has been limited using the --revision flag

The second condition is without effect if the --incremental flag is given, so that incremental dumps yield the same result as normal dumps.

The dump will only contain the repository's UUID if the following conditions are true:

  • The root of the repository is being dumped
  • There is no user prefix

both. both of them. it's an and, not an or, bestie. 🎀

🦋 ENVIRONMENT VARIABLES 🦋

  • TMPDIR — if TMPDIR is set, it specifies the directory to use for temporary files. Otherwise, /tmp is used.

⭐ EXIT STATUS ⭐

  • 0 on success 🎉
  • 1 on failure 😭

Any error messages will be printed to stderr.

👑 SEE ALSO 👑

svn(1), svnadmin(1), svndumpfilter(1)

the whole friend group. go say hi.

🎀 AUTHOR 🎀

Written by Jonas Gehring, <jonas@jgehring.net>

Copyright © 2008-present Jonas Gehring <jonas@jgehring.net>. Released under the GNU General Public License.

okay that's the whole page, you're fully educated, i'm so proud of you 🥹 this was rsvndump 0.6.1, documented 07/25/2025 — mwah, go dump something responsibly, ily, bye 💅✨🫶

📦 where this page comes from