RFC: Subversion support and phased upstream contribution plan

[Qiyuanqiii]

Origin: This proposal grew out of issue #1017: svn. Issue #1017 remains the home for the original request and future implementation tracking, while this thread gives us room to discuss the product direction, SVN semantics, and contribution plan together.

Context

Issue #1017 started with a straightforward question: could OpenCodeReview support Subversion? The follow-up comments brought a practical use case into focus. Teams working with SVN, especially in hardware and embedded development, need local working-copy reviews as well as reviews around repository revisions and remote merge workflows.

OpenCodeReview's review flow touches diff loading, historical content, search tools, session identity, delegate output, and editor integration. SVN support reaches across all of those layers, so it feels worth agreeing on the behavior and delivery plan before preparing upstream PRs.

I have put together and validated a working proof of concept in my fork. I would love to align it with the maintainers' expectations and reshape it into reviewable upstream contributions.

Proposed Semantics

Here is the behavior implemented by the proof of concept:

• Preserve the existing Git workflows and public interfaces.
• Detect Git first, then check for SVN metadata in the selected working directory.
• Review mutable SVN working-copy changes through status and diff data, including files outside version control.
• Interpret a single SVN revision as the exact change from rN-1 to rN; revision 0 uses an empty baseline.
• Compare SVN ranges through two exact endpoints, following SVN's repository-wide revision model directly.
• Accept paired remote source and destination targets for repository-side branch or merge review when both targets belong to the same SVN repository.
• Resolve moving revision spellings once and carry the resulting numeric revisions through diff loading, historical content, manifests, and resume identity.
• Invoke the system svn executable and keep the public Go dependency surface the same.
• Keep credentials private and runtime-only while session artifacts store stable repository identity and resolved revisions.

Proposed Upstream Delivery

I would like to keep #1017 as the umbrella issue and give each accepted phase its own upstream issue and focused PR:

Phase	Scope
1. Working-copy MVP	VCS detection, SVN root/status/diff handling, files outside version control, Git regression coverage, and minimal CLI documentation
2. Immutable revisions	Exact single-revision and revision-range review, frozen endpoints, historical content tools, manifest and resume semantics
3. SVN edge hardening	Copy/move ancestry, binary and property changes, sparse/mixed/switched working copies, externals, and repository identity
4. Remote targets	Paired source/destination URLs, repository-side comparison, automation from a plain directory, and credential-safe routing
5. Integration parity	Delegate and host-agent output, bundled skills, session viewer, VS Code support, installation guidance, and maintained documentation locales

The PRs can land one at a time. After one phase is merged, the next branch can start from the latest upstream main. Each PR would:

• Deliver a usable and tested slice of the feature.
• Use Part of #1017 and close its corresponding child issue.
• Include behavior tests, Git regression coverage, documentation, SPDX headers, and LF normalization required by the project.
• Reflect the feedback gathered from the previous phase.

If three broader phases would feel easier to review and maintain, I can reshape the plan around that preference as well.

Proof of Concept

The completed fork implementation provides a concrete reference for the design and test coverage:

• Fork implementation epic and acceptance criteria
• Working-copy phase
• Immutable revision phase
• SVN edge-hardening phase
• Remote-target phase
• Integration-parity phase

Validation covered a real local SVN repository and working copy, workspace/range/remote-target command flows, the full Go race suite, the repository coverage gate (90.5%), Git compatibility, VS Code tests and production builds, host-agent plugin tests, documentation tests, and checks that keep remote URLs within runtime routing.

For upstream, each phase can be recut on the latest main, narrowed to the agreed scope, and adjusted as review feedback comes in.

Questions for Maintainers

1. Does SVN support fit the project's roadmap and long-term maintenance scope?
2. Would a CLI working-copy MVP make a good first milestone, or would immutable revision support belong in that first slice too?
3. Do the exact revision and range semantics above match the behavior you would like OCR to expose?
4. Does the five-issue, sequential-PR plan feel comfortable to review, or would another split work better?
5. Should remote targets and VS Code integration follow after the core SVN provider lands?
6. Which architectural constraints or public interfaces would you like addressed before the first PR?

I would really appreciate the maintainers' guidance here. Once we have a shared direction, I can prepare the first child issue and upstream PR around the agreed milestone.

[springsheep]

1. CI: upstream GitHub Actions needs an SVN fixture (svnserve or pre-seeded
   repo) so the behavior tests actually run upstream, not just in your fork.
   Please include this in phase 1 scope.
2. Document the system svn CLI as a hard dependency (min version, Windows
   notes) in the phase-1 CLI docs.

[Qiyuanqiii]

@lizhengfeng101 (╥_╥)能看看吗

[lizhengfeng101]

Thanks for the detailed RFC and the fork implementation — clearly a lot of effort went into this.

That said, SVN support is unlikely to land in the main trunk in the near term. The main reason:

gitcmd.Runner as a concrete type currently permeates core paths — diff, scan, agent, tool, etc. There is no VCS abstraction layer. To bring SVN in, we would either need to extract interfaces across a huge surface area (which adds an ongoing "must not break SVN" tax on every Git-side evolution), or scatter if/else branches everywhere — neither is great for long-term trunk health.

The more practical issue is that Git and SVN have non-trivial semantic differences (revision model, branching model, working-copy state machine). It is not a matter of swapping one CLI for another. We still have a lot of work ahead on the Git ecosystem side (GitHub/GitLab/Codeup/Gerrit CI integration, session resume, VS Code extension, etc.), and with limited bandwidth we would rather not spread into a direction where the user base is shrinking.

Suggestions:

• Maintaining this as an independent fork is totally fine — teams that need SVN can use your version directly.
• If we ever introduce a VCS provider interface abstraction (no concrete plan for now), revisiting this as a plugin would make more sense at that point.

Again, appreciate your willingness to contribute — this is purely a roadmap trade-off, not a judgment on work quality.

[Qiyuanqiii]

Alright, I understand the team's decision. Thank you for taking the time to reply.