PgVN

The embedded monitoring console, captured from a recorded local validation run. Explore the console.

PgVN stores SVN repository history, configuration, and durable protocol state directly in PostgreSQL. Standard SVN clients continue to connect over svn://, HTTP, or HTTPS, while operators manage repositories through pgvnadmin (or the Windows GUI) and inspect runtime status through an embedded web console.

PgVN is built for teams that want to preserve standard SVN client workflows while consolidating repository storage, access policy, and operational state into a unified PostgreSQL backend. The runtime consists of a dedicated SVN service (pgvnserve), Apache DAV/authorization modules (mod_dav_pgvn and mod_authz_pgvn), and a command-line administration tool (pgvnadmin), all linked against a shared repository core.

The earlier PgFS filesystem-plugin PoC serves as the underlying storage engine, whereas deployments use the complete PgVN runtime. Local Polarion operation with PgVN has been confirmed by the project owner; broader scenario-by-scenario application acceptance continues under the validation roadmap.

The table describes the Windows preview's product capabilities. Linux availability is listed separately in Linux support; DAV, the monitoring HTTP/UI, and deployment tooling are not yet ported.

Linux x86_64 is a development target, not a complete distribution or production deployment package. The native binaries now run real repository operations against PostgreSQL, rather than only component probes. Windows packages, PowerShell deployment scripts, and PgVN Manager are not Linux installation tools.

Linux maintenance freeze is explicitly rejected before database access or child execution. CLI stdin cancellation is supported, but an already-running synchronous SQL call is not actively cancelled by a signal; the lock-wait test exits at PostgreSQL's configured statement timeout. Creating monitor tokens does not enable a Linux monitoring endpoint.

Linux monitoring CPU is normalized by online host CPUs, RSS is approximate, and private committed bytes are unavailable through this Linux implementation (not substituted with RSS or virtual size). Windows monitoring paths were not regression-tested; this component checkpoint does not enable telemetry in pgvnserve and keeps complete_product: false.

Use Linux x86_64, Python 3, and the verified SDK in the Ubuntu 24.04 builder environment. Follow the pinned SDK and builder preparation first; substitute your actual SDK path below (the preparation example uses linux-sdk-repro). Builds verify local inputs and do not implicitly download dependencies.

# Run inside the prepared builder environment; admin also builds pgvnserve.
python3 scripts/pgvn/build.py --target linux --components admin \
  --configuration Release --linux-sdk build/pgvn/linux-sdk
build/pgvn/linux/release-admin/bin/pgvnadmin --version
build/pgvn/linux/release-admin/bin/pgvnserve --version

The monitor data backend is a separate component-only build:

python3 scripts/pgvn/build.py --target linux --components monitor \
  --configuration Release --linux-sdk build/pgvn/linux-sdk

It produces a static backend library and a test probe under build/pgvn/linux/release-monitor/; it does not build an HTTP host or render the web UI. For ASan/UBSan, use --configuration Debug --sanitize; monitor output is then under build/pgvn/linux/debug-monitor-sanitized/.

Keep the output's bin/ and matching lib/ together. --components serve builds the service-only development component. For ASan/UBSan, use --configuration Debug --sanitize; admin output is then build/pgvn/linux/debug-admin-sanitized/.

Before starting a listener, create a separate database and login roles, then use the Linux administration guide to initialize schemas, grant permissions, create a protected key, and provision repository policy and credentials. The CLI does not create PostgreSQL databases or login roles; new repositories deny access by default. Configure the service role, key, identity domain, and listener using the native service guide, then run:

# After provisioning; replace the configuration path with your own UTF-8 file.
build/pgvn/linux/release-admin/bin/pgvnserve \
  --config /absolute/path/pgvnserve.ini --monitor-disabled

This runs in the foreground, not as an installed systemd service. Keep passwords and keys out of source control and shell history.

Recorded Release and ASan/UBSan runs each passed 24 native-service checks, 38 administration checks, 26 POSIX Hook component checks, and 39 monitoring backend checks in separate frozen builds; these are distinct component checkpoints, not a combined or full-product acceptance run. See the service evidence, admin evidence, Hook evidence, and monitor backend evidence.

The service/admin/monitor suites use PostgreSQL 18.6 in disposable containers with no published database ports. The corrected monitor runs observed builder image pgvn-linux-builder:24.04 and PostgreSQL image postgres:18.6 via docker image inspect; the runner does not gate on fixed image digests. The builder/test environment was Ubuntu 24.04.5, on an Ubuntu 22.04.5 outer host—not a clean Ubuntu 24.04 host deployment acceptance. Runner SDK paths may be absolute or repository-relative, but must resolve inside the repository mounted at /repo. run_linux_monitor.py accepts --builder-image <tag> to select another local builder image.

python3 tests/pgvn/run_linux_admin.py --sdk build/pgvn/linux-sdk --configuration Release
python3 tests/pgvn/run_linux_admin.py --sdk build/pgvn/linux-sdk --configuration Debug --sanitize
python3 tests/pgvn/run_linux_serve.py --sdk build/pgvn/linux-sdk --configuration Release
python3 tests/pgvn/run_linux_serve.py --sdk build/pgvn/linux-sdk --configuration Debug --sanitize
python3 tests/pgvn/run_linux_monitor.py --sdk build/pgvn/linux-sdk --configuration Release
python3 tests/pgvn/run_linux_monitor.py --sdk build/pgvn/linux-sdk --configuration Debug --sanitize

Never use a deployment database for tests. Admin stdin rendezvous checks use test-only SYS_PTRACE; Hook containment tests need a separate cgroup setup, not a production privilege template. Reports retain complete_product: false; remaining work is tracked in the Linux development plan.

The monitoring console is embedded directly in pgvnserve.exe—no Node.js, Python, or separate frontend service is required at runtime. It features a Chinese UI with light and dark themes, responsive desktop and narrow layouts, keyboard navigation, and automatic refresh with pause controls.

Console access is protected by expiring, revocable monitor:read tokens. Tokens are held only in browser memory; all repository, user, and policy changes are performed through pgvnadmin or PgVN Manager. See Web console and tokens for token commands.

flowchart TB
    CLIENT["Standard SVN clients"]
    WEB["Browser console"]
    OPERATOR["Operator / automation"]

    subgraph RUNTIME["Native Windows runtime components"]
        SERVE["pgvnserve<br/>SVN endpoint + embedded monitoring"]
        DAV["pgvnhttpd<br/>mod_dav_pgvn + mod_authz_pgvn"]
        ADMIN["pgvnadmin"]
        CORE["PgVN repository core<br/>linked into each component"]
        FS["PgFS storage engine"]
        SERVE --> CORE
        DAV --> CORE
        ADMIN --> CORE
        CORE --> FS
    end

    CLIENT -->|"svn://"| SERVE
    CLIENT -->|"HTTP / HTTPS"| DAV
    WEB -->|"read-only monitoring API"| SERVE
    OPERATOR --> ADMIN
    FS --> PG[("PostgreSQL<br/>history + catalog + policy + durable DAV state")]
    CORE -->|"catalog, policy and DAV state"| PG
    SERVE -->|"monitoring role"| PG
    DAV -->|"worker telemetry"| PG

A repository request follows three steps:

1. Resolve the repository. The protocol endpoint maps the incoming URL route to an internal repository ID. Internal IDs are separate from the client-visible SVN UUID, allowing a single database to host multiple repositories and routes.
2. Enforce policy. The shared core loads the published access configuration and evaluates path authorization and hook rules.
3. Read or write history. PgFS reads or writes versioned data in PostgreSQL. Revision publication and authorization-generation rechecks happen atomically within the same database transaction.

Because the shared core is linked directly into each service process, deployments require no separate repository RPC daemon. The web console reads operational metrics through the monitoring API, while administrative changes go through pgvnadmin or PgVN Manager.

Filesystem boundary. Each node still maintains local binaries, global configuration, protected keys, TLS certificates, logs, temporary files, and external hook executables. "No per-repository directories" means repositories and per-repository state do not rely on local folders (repo, conf, activities.d), though node-level deployment files remain on disk.

High availability boundary. Multiple service processes can share the same PostgreSQL backend. Database replication, primary election, fencing, and connection routing are the responsibility of the PostgreSQL deployment. PgVN does not perform database leader election, and local multi-process tests do not constitute acceptance of cross-host high availability or distributed multi-primary writes.

PgVN Manager is a native Windows desktop application (C# / WPF on .NET Framework 4.8) for configuring and maintaining a PgVN node. It provides a guided workflow to test PostgreSQL connectivity, provision a dedicated database and five non-superuser roles, initialize schemas and keys, save node configuration, install and control PgVN / DAV Windows services, and manage repositories, users, and access rules. Routine maintenance features include health checks, full history verification, SVN dump import/export, full backups, and log inspection. When publishing access rules, Manager verifies the configuration generation loaded for editing so concurrent administrator updates are never silently overwritten.

On a Windows x64 machine with .NET Framework 4.8 installed, run manager\PgVNManager.exe from the combined bundle, load the runtime directory, and follow the first-time setup workflow in the Chinese UI. PostgreSQL Server must be installed separately, and configuration or Windows service operations require administrator privileges. Full database/node restoration continues to use the PowerShell restore script. Local Polarion operation has been confirmed by the project owner; full application acceptance and cross-host HA validation remain pending.

The combined bundle is a single ZIP archive that packages the complete PgVN runtime together with PgVN Manager: pgvnserve, Apache / DAV modules, pgvnadmin, matching DLLs, client tools, deployment scripts, and the manager directory. For this iteration, the recorded local build artifact is runtime/pgvn-manager-bundle-9dce96de.zip (approx. 23 MiB) with a companion .zip.sha256 checksum file; see the delivery record. Because binary bundles are local build outputs distributed separately from Git source, copy both the ZIP and .sha256 file to the target machine, verify the checksum, and extract the archive. The extracted root directly contains bin, apache, deploy, tools, and manager—launch manager\PgVNManager.exe from there. By contrast, pgvn-manager.zip is a standalone GUI add-on that requires a separate complete runtime package. Neither archive includes the PostgreSQL Server installer, .NET Framework, or Polarion software and data.

To build PgVN Manager from source, run:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\tools\pgvn-manager\Build-PgVNManager.ps1

Build outputs are written to runtime/pgvn-manager. Pass -RuntimePackageZip <verified-runtime.zip> to produce the combined runtime + GUI bundle. PgVN Manager records its own build manifest (manager-manifest.json). See the Manager guide for usage details, test scripts, and restore boundaries, and the local validation record for verification evidence.

This procedure covers an isolated Polarion evaluation copy on the same Windows host: migrating its default SVN repository history into PostgreSQL and switching Polarion to access PgVN over HTTP and SVN. PgVN Manager handles database initialization, dump import, and routine maintenance, while source repository export, polarion.properties updates, and application-level verification are performed manually. While the project owner has confirmed local Polarion operation, each item in the full application checklist below still requires dedicated acceptance records.

Work strictly against an isolated Polarion test copy. Every C:\Polarion path below refers to that isolated copy—never share a data directory with a running production or primary instance. Prepare the combined runtime and GUI bundle, .NET Framework 4.8, and a running PostgreSQL instance. Extract the bundle to C:\PgVN-PolarionEval while keeping the original Polarion installation and FSFS repository intact. Record the existing Windows service names, startup types, repository UUID and HEAD revision, authentication mode, authorization rules, active locks, and hooks. Back up all configuration and application data, and take a final consistent backup after freezing writes right before exporting.

Example migration parameters (adjust the database port to match your PostgreSQL instance):

Run C:\PgVN-PolarionEval\manager\PgVNManager.exe as Administrator and load C:\PgVN-PolarionEval. Under 初始化与连接 (Initialization and Connection), enter the PostgreSQL host, port, new database name, and role prefix, and set the SVN / monitor / HTTP ports to 14690 / 14691 / 14980. Click 测试 DBA 连接 (Test DBA Connection), re-enter the DBA password (which clears after testing), and click 创建数据库并初始化 (Create Database and Initialize). PgVN uses its own dedicated database; leave Polarion's existing internal SQL / index database configuration untouched.

Under 仓库与用户 (Repositories and Users), create the repository polarion with route /svn/polarion. Keep target services stopped and do not commit test files: GUI dump import only accepts an empty r0 repository. If any port is already in use, adjust it in Manager and update all corresponding URLs in the steps below.

Enter a maintenance window for the Polarion test copy. Stop the Polarion application service along with every HTTP / SVN service, scheduled job, and integration endpoint capable of writing to the source repository or modifying revision properties. Following the maintenance guide for your Polarion version, take a consistent backup covering at least polarion.properties, the original Apache SVN configuration, the FSFS repository, authentication/authorization files, hooks, and the matching application data/index rollback point. Stopping the Polarion web UI alone does not prevent background or direct SVN writes.

In an elevated PowerShell session, create a restricted staging directory (D:\Polarion-migration), adjust paths to match your environment, and export the source repository. The bundled svnadmin dump supports --file, which preserves exact binary stream output:

$SourceSvn = 'C:\Polarion\bundled\svn\bin'
$SourceRepo = 'C:\Polarion\data\svn\repo'
$Dump = 'D:\Polarion-migration\polarion-final.dump'
if (Test-Path -LiteralPath $Dump) { throw 'Choose a new export filename' }
& "$SourceSvn\svnadmin.exe" verify $SourceRepo
if ($LASTEXITCODE) { throw 'Source verification failed' }
$SourceHead = & "$SourceSvn\svnlook.exe" youngest $SourceRepo
if ($LASTEXITCODE) { throw 'Cannot read source HEAD' }
$SourceUuid = & "$SourceSvn\svnlook.exe" uuid $SourceRepo
if ($LASTEXITCODE) { throw 'Cannot read source UUID' }
& "$SourceSvn\svnadmin.exe" dump $SourceRepo -r "0:$SourceHead" --file $Dump
if ($LASTEXITCODE) { throw 'Source export failed' }
$SourceHead; $SourceUuid
Get-FileHash -LiteralPath $Dump -Algorithm SHA256

Record $SourceHead, $SourceUuid, and the SHA-256 hash of the dump file. If another SVN distribution does not support dump --file, redirect stdout in cmd.exe (svnadmin dump ... > file.dump); never use Windows PowerShell 5.1 text pipelines or > redirection on binary dump streams, and do not use Manager's "Export current repository" button to export a legacy FSFS repository.

In Manager, select polarion, open 备份与维护 (Backup and Maintenance), and click 导入到当前空仓库 (Import into Current Empty Repository) to load the dump file. Manager disables the repository before importing and leaves it disabled afterward. Run 校验当前仓库历史 (Verify Current Repository History) and confirm that the reported HEAD matches $SourceHead. If the import fails, preserve the logs and retry into a newly created empty repository rather than appending to a partially imported one.

Under 仓库与用户 (Repositories and Users), create credentials for the Polarion system account specified by login in polarion.properties, using the password matching its password setting, and check 同步 DAV / HTTP Basic 凭据 (Synchronize DAV / HTTP Basic Credentials). The example below uses polarion; substitute your actual system username if different. Create matching accounts and credentials for any evaluation users participating in testing. Note that SVN / DAV accounts are completely separate from PostgreSQL database roles.

Click 读取当前规则 (Load Current Rules), edit the authz rules to match your source system's effective path permissions, and publish them. The minimal bootstrap rule below is only suitable for single-administrator startup on an isolated test copy—it does not migrate multi-user or project-level permissions:

[/]
polarion = rw
* =

In the inspected default Polarion configuration, /repo uses DBD (or optional LDAP) authentication and reads path authorization from /.polarion/access inside the SVN repository; inspect your own installation to confirm its exact setup. PgVN's deployment template instead uses a dedicated DAV password file and versioned policies stored in PostgreSQL. Having /.polarion/access inside an imported dump does not cause PgVN to enforce it automatically. Furthermore, PgVN Manager does not automatically sync user creation, password changes, groups, or permission updates made inside Polarion. Before starting multi-user testing, migrate your effective authz rules and groups, set up ongoing synchronization and authentication adaptation for your environment, and verify both allowed and denied paths. Until then, restrict testing to fixed accounts. For CLI management of groups and policies, see the Administration guide.

Standard SVN dumps also exclude source hook scripts, server configuration, and active locks; handle these separately per the Subversion migration FAQ. Adapt any Polarion-required hooks to PgVN's global hooks directory and database hook policy: PgVN invokes .exe hook binaries and passes JSON event payloads over stdin (see External hooks). Verify hook arguments and Polarion notification behavior—legacy batch/shell scripts or hooks that inspect local FSFS filesystem paths cannot be copied verbatim. Do not proceed to cutover if required authentication, authorization, hook, or lock handling remains unresolved.

Once history verification and access policies are ready, enable the polarion repository under 仓库与用户 (Repositories and Users). Open 服务管理 (Service Management), enter the two distinct service names (PgVN-PolarionEval and PgVNDAV-PolarionEval), check 同时安装 HTTP / DAV 服务 (Also install HTTP / DAV service), and run 安装服务 (Install), 启动 (Start), and 运行健康检查 (Run Health Check). Then verify both protocol endpoints using the system account (enter the password when prompted):

$PgRoot = 'C:\PgVN-PolarionEval'
& "$PgRoot\tools\svn\svn.exe" info 'http://127.0.0.1:14980/svn/polarion/' --username polarion --no-auth-cache
& "$PgRoot\tools\svn\svn.exe" info 'svn://127.0.0.1:14690/svn/polarion' --username polarion --no-auth-cache

Confirm that both endpoints return the exact $SourceUuid and $SourceHead recorded prior to export. Spot-check historical revisions, project directories, attachments, and versioned properties, and verify that restricted users are denied access as expected. Passing the service health check alone does not prove Polarion compatibility. Always use a fresh working-copy checkout for initial rehearsals rather than reusing working copies bound to legacy URLs.

With the Polarion application still stopped, back up and edit C:\Polarion\polarion\configuration\polarion.properties. Update the repository endpoints in place (modify existing lines rather than adding duplicate keys):

repo=http://127.0.0.1:14980/svn/polarion/
repoSystem=svn://127.0.0.1:14690/svn/polarion

Here, repo is the primary repository endpoint, while repoSystem is an optional system read-only endpoint that must resolve to the same repository UUID. For an initial test, you may comment out repoSystem so system reads also use repo; ensure any legacy file:// or old SVN URLs are updated or commented out. Keep login and password aligned with the credentials configured in PgVN Manager, and preserve base.url, Tomcat settings, and Polarion's internal database settings. Consult the version-specific Deployment and Maintenance Guide on the Siemens documentation portal for any version-specific requirements.

Before starting Polarion's bundled Apache server for the web UI, fence off legacy repository write locations (such as /repo and /installrepo) in the backed-up Apache configuration—for example, replace the existing authorization directives inside each matching <Location> block with Require all denied, test the Apache configuration syntax, and then start Apache. Simply appending a deny rule alongside existing allow rules is not sufficient. Keep all other legacy SVN services and write tasks stopped so the old FSFS repository cannot accept writes. Start services in order: PostgreSQL → PgVN / DAV ready → Polarion application. Note that services installed by PgVN Manager default to Manual startup; configure automatic startup and service dependencies separately if testing host reboots.

The 127.0.0.1 URLs above are strictly for same-host evaluation. Remote SVN clients or browsers require a reachable HTTPS endpoint, valid TLS certificates, and matching URL settings—127.0.0.1 on a client machine will not reach the server.

Log in to Polarion and verify project listings, work-item reads and writes, LiveDocs, attachments, history and baselines, locks, path restrictions for non-admin users, and synchronization of user/group/password/permission changes. Run indexing and reindexing according to your Polarion version's maintenance guide, verify that new commits land exclusively in PgVN while the old FSFS repository HEAD stays frozen, and take a full backup in PgVN Manager. Record all findings before expanding the evaluation scope. Although local Polarion startup and operation have been confirmed by the project owner, each scenario in this checklist still requires formal verification before production use.

To roll back: first stop Polarion and all write sources, then stop the PgVN-PolarionEval and PgVNDAV-PolarionEval services in Manager.

• If no new writes occurred in PgVN: restore the backed-up polarion.properties, Apache configuration, and matching application data/index rollback point, then restart the original SVN and Polarion services in their normal order.
• If new commits or revision-property edits occurred in PgVN: first take a complete PgVN backup and export the new history, then have an administrator migrate the updated repository back to a separate FSFS directory and verify it. Do not simply re-enable the old FSFS repository at its pre-cutover HEAD, as doing so will lose all post-cutover changes.

This quick start is for Windows; Linux developers should use Linux support. Run steps 1–5 in a single elevated PowerShell session. Deploy the PostgreSQL server separately; the PgVN runtime package includes PostgreSQL and SVN client binaries.

The pinned build stack uses Subversion 1.14.5, Apache HTTP Server 2.4.68, APR 1.7.6, and APR-util 1.6.3. These versions represent the tested build baseline rather than a cross-version compatibility matrix.

Always deploy a complete, matching Windows x64 runtime package containing the executables, DLLs, custom Apache host, DAV modules, and deployment scripts. Obtain the ZIP archive and .sha256 file from a trusted build output, verify the checksum, and extract the archive. Simply copying two DLLs into an existing Subversion or Apache directory is not supported.

In an elevated PowerShell session, replace PACKAGE_ID with your actual package identifier:

$zip = 'C:\Transfer\PgVN-M5-windows-x64-PACKAGE_ID.zip'
$expected = (Get-Content -LiteralPath ($zip + '.sha256') -Raw).Split(' ')[0]
if ((Get-FileHash -LiteralPath $zip -Algorithm SHA256).Hash -ine $expected) {
    throw 'ZIP checksum mismatch'
}
Expand-Archive -LiteralPath $zip -DestinationPath 'C:\Deploy'
$root = Join-Path 'C:\Deploy' ([IO.Path]::GetFileNameWithoutExtension($zip))
& "$root\deploy\windows\Test-PgVNPackage.ps1"

The archive extracts into a top-level folder matching the ZIP base name ($root), containing bin, apache, deploy, and tools. Test-PgVNPackage.ps1 verifies file hashes, x64 PE dependencies, and UTF-8 process startup (process_code_page=65001). To build a package locally, see Build from source; for package layout and verification details, see the Packaging guide.

As a PostgreSQL DBA, create a dedicated UTF-8 database and five non-superuser roles:

CREATE ROLE pgvn_migrate LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE ROLE pgvn_admin LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE ROLE pgvn_service LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE ROLE pgvn_monitor LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE ROLE pgvn_restore LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;
CREATE DATABASE pgvn OWNER pgvn_migrate ENCODING 'UTF8' TEMPLATE template0;

Set passwords for each role interactively using \password in psql, and configure network access (pg_hba.conf). The command below targets local port 5432 (note that destructive fault-injection tests in this repository use a separate isolated cluster on port 16432):

& "$root\deploy\windows\Initialize-PgVNConfiguration.ps1" `
    -DatabaseHost '127.0.0.1' -DatabasePort 5432 -DatabaseName pgvn `
    -NodeId node-1 -SvnPort 14690 -MonitorPort 14691 -HttpPort 14980

Populate the generated password files—admin\secrets\pgpass.conf for migration/admin roles and secrets\runtime.pgpass.conf for service/monitor roles—while preserving their restricted NTFS ACLs. pgvn_migrate owns the database schemas, while administration, client request handling, monitoring, and isolated restores run under their respective least-privilege roles. When connecting to a remote PostgreSQL server, configure CA trust and hostname-verified TLS (verify-full) as documented in the Windows deployment guide. Re-running Initialize-PgVNConfiguration.ps1 preserves existing configuration files rather than overwriting them with new parameters.

PgVN-M5-windows-x64-PACKAGE_ID/
├─ bin/                 pgvnserve, pgvnadmin, and matching runtime DLLs
├─ apache/              Custom Apache host (pgvnhttpd) and DAV/authz modules
├─ deploy/windows/      Installation, verification, user, and backup/restore scripts
├─ tools/               Pinned SVN and PostgreSQL client binaries
├─ config.local/        Node service configuration (generated during initialization)
├─ admin/               Admin configuration, pgpass file, and service registry (generated)
├─ secrets/             Runtime pgpass file and credential encryption keys (populated after init)
├─ hooks/               Global directory for external hook executables (generated)
└─ logs/, state/        Node logs, temporary files, and runtime state (generated)

$admin = "$root\deploy\windows\Invoke-PgVNAdmin.ps1"
& $admin -Profile Migrate -Arguments @('db','init','--json')
if ($LASTEXITCODE) { throw 'Database initialization failed' }
& $admin -Profile Migrate -Arguments @('db','check','--json')
& $admin -Profile Migrate -Arguments @('db','grant','--admin-role','pgvn_admin','--service-role','pgvn_service','--monitor-role','pgvn_monitor','--json')
& $admin -Arguments @('key','create',"$root\secrets\credentials-v1.key",'deployment-v1')

$password = Read-Host 'Password for SVN/DAV user alice' -AsSecureString
& "$root\deploy\windows\Set-PgVNUser.ps1" -UserName alice -Password $password -AlsoDav
& $admin -Arguments @('repo','create','demo','--route','/svn/demo','--json')

Passing -AlsoDav provisions both the encrypted SVN credential in PostgreSQL and the entry in Apache's HTTP Basic password file. Both protocols authenticate against their respective credential stores and enforce the same database-backed path authorization policy.

Newly created repositories deny all access by default. Write admin\demo.authz encoded as UTF-8 without BOM, publish the policy, and install and verify the Windows services:

$authz = @'
[demo:/]
alice = rw
* =
'@
[IO.File]::WriteAllText("$root\admin\demo.authz", $authz, [Text.UTF8Encoding]::new($false))
& $admin -Arguments @('config','show','name:demo','--json')
# Generation 1 applies only to a newly created, unmodified repository.
# For an existing repository, pass the actual generation returned by `config show`.
& $admin -Arguments @('config','publish','name:demo','--expected-generation','1','--authz',"$root\admin\demo.authz",'--json')
& $admin -Arguments @('authz','check','name:demo','alice','/','write','--json')
& "$root\deploy\windows\Install-PgVNServices.ps1"
& "$root\deploy\windows\Test-PgVNDeployment.ps1" `
    -RepositoryRoute /svn/demo -UserName alice -Password $password

Install-PgVNServices.ps1 registers the PgVN and PgVNDAV Windows services under the NT AUTHORITY\LocalService account. By default, all listeners bind to 127.0.0.1:

Before exposing services to remote clients, configure HTTPS with trusted certificates and appropriate firewall rules. Because CRAM-MD5 authenticates svn:// without encrypting wire traffic, route remote svn:// connections through a trusted tunnel. PostgreSQL connections must preserve session-level state; do not place a transaction-mode connection pooler between PgVN and PostgreSQL.

Get-Service -Name PgVN, PgVNDAV
Invoke-RestMethod -Uri 'http://127.0.0.1:14691/health/live'
Invoke-RestMethod -Uri 'http://127.0.0.1:14691/health/ready'

Both Windows services should report Running, and the health endpoints should return live: true and ready: true. Test-PgVNDeployment.ps1 also verifies that the embedded console is reachable and that both svn:// and http:// report the same repository UUID. Next, follow Web console and tokens to mint a read-only token and sign in at http://127.0.0.1:14691/monitor/.

Use the bundled SVN CLI (or any standard SVN client). The commands below continue in the same PowerShell session with the alice account created during setup:

$svn = "$root\tools\svn\svn.exe"
& $svn checkout svn://127.0.0.1:14690/svn/demo demo --username alice
Set-Content -LiteralPath .\demo\hello.txt -Value 'Hello from PgVN' -Encoding UTF8
& $svn add .\demo\hello.txt
& $svn commit .\demo -m 'Initial commit' --username alice
& $svn update .\demo --username alice
& $svn log svn://127.0.0.1:14690/svn/demo --username alice
& $svn ls http://127.0.0.1:14980/svn/demo --username alice
& $svn cat http://127.0.0.1:14980/svn/demo/hello.txt --username alice

The final svn cat command reads Hello from PgVN over HTTP/DAV immediately after it was committed over svn://. Combined with the matching repository UUIDs verified during deployment, this confirms that both protocols operate on the same underlying PostgreSQL repository. You can also inspect the updated HEAD revision in the web console's Repositories view.

Always invoke pgvnadmin through the Invoke-PgVNAdmin.ps1 wrapper so it loads the protected libpq configuration and matching runtime DLLs:

& $admin -Arguments @('repo','list','--json')
& $admin -Arguments @('repo','show','name:demo','--json')
& $admin -Arguments @('verify','name:demo')
& $admin -Arguments @('dump','name:demo','--file','D:\Backup\demo.dump','--deltas')

To migrate history from an existing SVN repository, export a standard SVN dump file and load it into a new, empty target repository:

& $admin -Arguments @('repo','create','imported','--route','/svn/imported','--json')
& $admin -Arguments @('repo','disable','name:imported','--json')
& $admin -Arguments @('load','name:imported','--file','C:\Transfer\existing.dump')
& $admin -Arguments @('verify','name:imported')
& $admin -Arguments @('config','show','name:imported','--json')

After verification succeeds, prepare the authz file for imported (using [imported:/] for repository-qualified sections), publish it with the generation number returned by config show, and enable the repository with repo enable name:imported. Always pass --file rather than piping dump streams through Windows PowerShell text redirection. Note that dump/load migrates versioned history only—user credentials, access policies, and hooks must be configured separately. See the Administration guide for full details.

& $admin -Arguments @('monitor-token','create','--label','local-ops','--expires-in','3600')
# Open http://127.0.0.1:14691/monitor/ and paste the returned secret token.
& $admin -Arguments @('monitor-token','list','--json')
# Replace TOKEN_ID with the token ID from `list`, not the raw secret value.
& $admin -Arguments @('monitor-token','revoke','TOKEN_ID','--json')

The raw secret token is displayed only once upon creation and grants monitor:read permissions exclusively; never embed it in URLs. Because tokens are kept only in browser page memory, reloading the page prompts for authentication again, and token expiration or revocation immediately disconnects the session and clears displayed operational data.

After initialization, you can adjust the SVN listener address and session concurrency limit in config.local\pgvnserve.ini (preserve the generated database connection and key settings in the file):

[pgvn]
node-id = node-1
listen-host = 127.0.0.1
listen-port = 14690
max-connections = 64

max-connections defaults to 64 (valid range: 1–64) and takes effect after restarting the PgVN service. It caps concurrent svn:// protocol connections on the node; note that a single SVN client command may open multiple parallel connections. The web console, monitoring API, and Prometheus endpoint report the active max-connections ceiling of the running instance.

Business-database connection leases are capped separately at 32 per process; neither limit should be interpreted as a guaranteed concurrent user count or throughput target. In multi-node deployments, assign each node a unique node-id and coordinate credential keys, hook executables, and node configurations across hosts. See the SVN service guide for details.

& "$root\deploy\windows\Backup-PgVN.ps1" -Destination 'D:\PgVN-backups\snapshot-01'

Backup-PgVN.ps1 captures a consistent logical database backup alongside protected node configuration files, keys, DAV password files, and global hooks. To restore, run Restore-PgVN.ps1 against an empty, separate PostgreSQL database, then verify configuration and repository history before starting services. The current control schema version is 6. Because schema downgrade migrations are not supported, rolling back an upgrade requires restoring the matching database backup, keys, and configuration files.

In multi-node deployments, coordinate key rotation, hook binaries, and configuration versions across all nodes—a database snapshot alone does not back up node-local files on peer hosts. Follow the Windows deployment guide for complete backup, restore, and upgrade procedures.

Node logs are written to $root\logs (default DAV logs are apache-error.log and apache-access.log). See the Windows deployment guide for detailed diagnostics.

Building Windows from source requires Python 3, LLVM-MinGW, and the pinned upstream source trees and SDKs. For Linux, use the native build instructions. Copy config/build.example.json to config/build.local.json (which is Git-ignored) and configure your local paths. External SDKs and any local Polarion installation are treated strictly as read-only inputs.

Copy-Item -LiteralPath config/build.example.json -Destination config/build.local.json
# Edit config/build.local.json with your local SDK and upstream source paths.
python scripts/pgvn/fetch_httpd.py
python scripts/pgvn/build.py --config config/build.local.json --configuration Release
python scripts/pgvn/package.py --development

fetch_httpd.py explicitly downloads and verifies checksum-pinned Apache HTTP Server sources. For offline builds, pre-stage those archives and point apache_source to the local directory (see Windows UTF-8 build notes); build.py never accesses the network implicitly. Compiled binaries are placed in runtime/pgvn, build provenance in artifacts/pgvn/build/manifest.json, and distributable archives in runtime/pgvn/packages.

Product and dependency versions, schemas, and capabilities now share src/pgvn/version.json. New runtime metadata, package manifests, and generated GUI version attributes use this source; freezing a build checks the actual APR/APR-util/libpq versions. The rebuilt GUI requires a matching runtime package and checks its version, API, schemas, and capabilities. Previously documented bundles retain their original build identity.

Linux build-metadata checks can also run without SDKs:

python scripts/pgvn/build.py --metadata-only --target linux --configuration Release
python -m unittest discover -s tests/pgvn -p test_build_metadata.py -v

--metadata-only prepares the version header and source/migration inventories under build/pgvn/metadata/linux/; it does not build Linux server or module binaries. See the execution checkpoint for package pairing, remaining Windows validation, and the implementation sequence.

Linux now includes native pgvnserve, pgvnadmin, POSIX external Hook execution, and a separately verified monitoring data backend; see Linux support for build/run commands and limits. Earlier FS/SDK, credential, Hook configuration, and monitor backend checkpoints remain component-specific evidence. Current catalog schema 8 includes versioned logical Hook declarations and node-local mappings; historical packages retain their original schema and capabilities.

Run test gates via scripts/pgvn and tests/pgvn. Full M5 validation requires real-browser evidence, a configured JDK + SVNKit environment, and the dedicated test PostgreSQL cluster; see Browser and test prerequisites and the M5 development notes. Because test gates provision isolated databases, register temporary services, and occasionally restart the test PostgreSQL cluster, never point test scripts at a deployment database. Legacy PgFS scripts and test outputs are retained as historical references only and do not represent current PgVN acceptance.

src/pgvn/             Native SVN server, shared repository core, CLI admin tool, and Apache DAV/authz modules
src/libsvn_fs_pg/     PgFS PostgreSQL-backed Subversion storage engine
web/pgvn-monitor/     Embedded monitoring console HTML, CSS, and JavaScript
tools/pgvn-manager/   Native Windows configuration and maintenance GUI (C# / WPF)
sql/                  Versioned PostgreSQL schema migrations
scripts/pgvn/         Build orchestration, dependency preparation, and packaging scripts
tests/pgvn/           Milestone verification gates and upstream SVN compatibility fixtures
deploy/windows/       Windows PowerShell configuration, service, and backup/restore scripts
docs/pgvn/            Architecture specs, operational guides, and validation evidence

First usable preview — Windows (2026-10-17). The project owner confirmed successful local Polarion operation with PgVN; see the operation record for scope details. All previously recorded compatibility results and remaining milestone requirements remain in effect.

Linux development checkpoints: native service, administration CLI, and POSIX Hook execution have separate recorded checks; Linux support lists their scope. They do not extend the Windows milestone acceptance below to Linux or complete M6/M7.

Recent validation records are summarized below. Each record applies strictly to the build hash identified in its report; completing a test run does not imply full upstream compatibility or production readiness.

Known client boundaries: SVNKit 1.10.1 double-encodes non-ASCII repository URLs when modifying revision properties, and the pinned svnmucc binary exhibits a non-ASCII username disconnect that also reproduces against stock svnserve + FSFS. Use ASCII repository routes when supporting SVNKit 1.10.1 clients. See DAV compatibility and Windows UTF-8 validation for details.

Both the English and Chinese READMEs cover the product overview, Linux development, Polarion GUI migration, and quick-start workflows. Most detailed engineering and operational guides are in Chinese; the Linux service, CLI, and monitoring backend guides are in English:

Original PgVN source code and documentation are licensed under the Apache License, Version 2.0 (Apache-2.0). See NOTICE for attribution details. Third-party dependencies retain their respective licenses; runtime packages include their license texts under licenses/, including the Phosphor Icons MIT notice also embedded in the monitoring console HTML.