Apache Subversion Documentation

repository·trunk·Indexed 20 days ago

https://github.com/apache/subversion

Documentation for Apache Subversion, including details on the utf8proc C library for Unicode normalization and encoding, the JavaHL high-level Java API, and SWIG-based Python and Ruby bindings for interacting with Subversion client operations and repository management.

Tokens
21.7K
Snippets
59
Records
98
Agent score
70%

What's inside Apache Subversion

  1. Compare 1.8 and 1.15 working copy formats

    trunk

    Subversion 1.15 supports two distinct working copy formats:

    Feature1.8-compatible (Format 31)1.15-compatible (Format 32)
    DefaultYes (default for SVN 1.15)No
    i525pod SupportNoYes
    WC StateNever "bare"Becomes "bare" immediately
    CompatibilityAccessible by SVN 1.8+Accessible only by SVN 1.15+
    ReversibilityN/ACannot be converted back to 1.8
  2. Disk space usage with i525pod

    trunk

    The i525pod feature significantly reduces the disk footprint of a Working Copy.

    Feature StateTypical Disk Usage
    Standard (No i525pod)~2x the size of working files (contains a pristine copy of every unique file)
    With i525podSlightly greater than the size of working files (only stores pristines for modified files)

    Behavior Details

    • Initial Size: A fresh checkout stores no pristines. Upgrading an existing WC to 1.15 will remove pristines for all unmodified files.
    • Growth/Shrinkage: Disk usage fluctuates as you modify files (triggering hydration) or commit files (triggering dehydration).
    • Commit Behavior: Running svn commit will remove the pristines for the files being committed.
    • When benefits are minimal: The feature provides less benefit if a large proportion of files are duplicates or if the WC is specifically structured to only contain files intended for modification.
  3. Understand the i525pod (Pristines on Demand) feature

    trunk

    The i525pod feature (implemented in Subversion 1.15) optimizes disk space usage by only storing pristine copies (text bases) for files that are currently in a locally modified state.

    Key Concepts

    • Pristine copy / text base: A copy of a file's content matching the base revision in the repository, used for local diffs, reverts, and delta updates.
    • Hydrate: Fetching a pristine copy from the repository and storing it in the Working Copy (WC) metadata area.
    • Dehydrate: Removing a pristine copy from the WC metadata area to save space while remembering it may be needed again.
    • Sync scope: The set of WC paths that a Subversion operation checks to determine which pristines need to be hydrated or dehydrated. This is typically a superset of the files actually used by the operation.
    • Bare WC: A state where the feature is enabled and the WC contains only a subset of pristine copies.
  4. Functional differences when using i525pod

    trunk

    When i525pod is enabled, certain operations that were previously offline now require repository contact to "hydrate" necessary pristine copies. This may require authentication and can introduce a delay before the command begins its primary task.

    Operations that may now require repository contact (Hydration)

    • svn cat (base version)
    • svn diff (base against working)
    • svn resolve (including conflict resolution in merge or update)
    • svn revert

    Operations that were already online and remain online

    • svn diff (comparing repository to WC)
    • svn merge
    • svn resolve
    • svn switch
    • svn update
    • svn checkout --force

    Important Notes

    • Authentication: Hydrating pristines requires its own connection and authentication. Depending on your configuration, you might be prompted for a password an additional time.
    • Progress Feedback: Most commands output progress like Fetching text bases ... with dots representing files fetched. However, svn diff and svn cat do not provide progress feedback and may appear to hang while hydrating.
  5. Set up the svnpubsub service

    trunk

    To use svnpubsub, you must first deploy the service to your server.

    1. Check out the svnpubsub directory to /usr/local/svnpubsub (or /opt/svnpubsub on Debian systems).
    2. Initialize the service using the provided init scripts located in the rc.d/ directory. Add these scripts to your operating system's boot process (e.g., using rc.conf(5) or update-rc.d(8) depending on your OS).
  6. Enable i525pod for a Working Copy

    trunk

    The i525pod feature is an optional component of Subversion 1.15. It is enabled on a per-Working Copy basis by upgrading the WC to the 1.15-compatible format.

    Warning: Once a Working Copy is upgraded to the 1.15 format, it is no longer compatible with older Subversion clients (1.8 through 1.14) and cannot be downgraded.

    To enable the feature, use either a fresh checkout or upgrade an existing WC using the --compatible-version=1.15 flag.

    # For a new checkout
    svn checkout --compatible-version=1.15 <URL>
    
    # For an existing working copy
    svn upgrade --compatible-version=1.15
  7. Install and build utf8proc

    trunk

    You can build the utf8proc C library using make or cmake.

    Using Make

    • Build: Run make to compile the library.
    • Install: Run make install to install the library and header files. By default, these are installed to /usr/local/lib and /usr/local/bin. You can specify a custom directory using make prefix=/some/dir.
    • Test: Run make check to execute tests.
    • Clean: Run make clean to remove generated files.

    Using CMake

    To build using CMake, create a build directory and run the following:

    mkdir build
    cmake -S . -B build
    cmake --build build
  8. Use the i525pod feature in a working copy

    trunk

    To use the i525pod feature, the working copy (WC) must use the 1.15-compatible format (WC format 32). This format is required for i525pod functionality and results in a "bare" working copy.

    Important constraints for 1.15-compatible format:

    • The working copy becomes "bare" immediately.
    • It is no longer accessible by Subversion clients older than version 1.15.
    • It cannot be converted back to a 1.8-compatible format.

    You can either create a new working copy in this format or upgrade an existing one.

    # To check out a new working copy in 1.15-compatible format
    svn checkout --compatible-version=1.15
    
    # To upgrade an existing working copy to 1.15-compatible format
    svn upgrade --compatible-version=1.15
  9. Configure Subversion post-commit hooks for svnpubsub

    trunk

    To broadcast repository changes via svnpubsub, you must trigger the commit-hook.py script from your Subversion repository's post-commit hook.

    Pass the repository path and the revision number as arguments: commit-hook.py $REPOS $REV

    Note: Since version 1.7, commit-hook.py accepts the same ordered arguments as the standard post-commit hook. If you do not require any other hooks to run in the server process, you can simply symlink commit-hook.py as your hooks/post-commit script.

    commit-hook.py $REPOS $REV
  10. Upgrade working copy formats

    trunk

    The svn upgrade command is used to transition working copies between compatibility formats.

    • Default behavior: svn upgrade (or svn upgrade --compatible-version=1.8) upgrades a working copy to the 1.8-compatible format. This is useful for upgrading WCs from version 1.7 or older so that Subversion 1.8+ clients can use them.
    • Upgrading to 1.15: You can upgrade to the 1.15-compatible format (WC format 32) from either 1.8-compatible format or 1.7-compatible (and older) formats.
    • Downgrading: You cannot downgrade a working copy to an older format. If you require an older format, you must perform a new checkout using an older Subversion client.
    # Upgrade to 1.8-compatible format (default)
    svn upgrade
    
    # Upgrade to 1.15-compatible format (required for i525pod)
    svn upgrade --compatible-version=1.15
  11. Overview of JavaHL

    trunk

    JavaHL is a high-level Java API for Subversion that provides a mostly native implementation using JNI (Java Native Interface). It is designed for developers implementing GUI clients or IDE plug-ins for Subversion.

    Key characteristics:

    • It exposes a minimal-but-complete set of APIs that map to the core Subversion C API.
    • It requires a JRE 1.8 or higher at runtime.
    • It produces both a native library (libsvnjavahl-1.so on Unix, libsvnjavahl-1.dll on Win32) and a platform-independent Java bytecode archive (svn-javahl.jar).