Private corporate batches, live online cohorts and 1-on-1 mentoring in operating a legacy SVN estate safely, and converting it to Git without losing history, branches or the audit trail — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches SVN from the position most teams are actually in: an estate that must keep working while it is being replaced. That means the operational side — hooks, path-based authorisation, dump and load, svnsync mirrors and restore-tested backup — alongside the conversion side: auditing non-standard layouts, building an authors map, converting branches and tags with git-svn and svn2git, moving large binaries to Git LFS, and running a cutover with a verification pass and a rollback position. He also teaches the part that is usually skipped — replacing locks, externals and path-based access control with equivalents that actually exist in Git.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For SVN that means a trainer who has run it in production — operating a legacy SVN estate safely, and converting it to Git without losing history, branches or the audit trail — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private SVN batchSVN is the everyday name for Apache Subversion, the centralised version control system whose client command is literally svn. One server holds the authoritative history, developers check out working copies, and every commit advances a single repository-wide revision number. That number is the reason so many SVN estates are still running: it is stamped into build outputs, defect trackers, release notes and audit records, and nothing in a distributed system reproduces it exactly.
This page is deliberately narrower than a full Subversion course. It is for teams who already have an SVN estate and now have two jobs at once — keep it running safely, and get off it. Those jobs need different skills. Keeping it running means hooks, path-based authorisation, backups that restore, and a team that understands mixed-revision working copies and svn:mergeinfo well enough not to damage history further. Getting off it means auditing repository layout, mapping authors, converting branches and tags, deciding what history is worth carrying, and running a cutover that a release manager will sign.
The hard part of an SVN migration is rarely the conversion command. It is the concepts that do not survive the crossing: branches that were directory copies, locks on unmergeable binaries, externals that stitched several repositories together, and path-based access control that let one team read a subtree and nothing else. Each needs a deliberate replacement in Git, or the migration lands and the team quietly regresses.
Most SVN estates are now maintained by people who did not build them. The engineers who chose the layout, wrote the hooks and configured the authorisation file have moved on, and what remains is a repository nobody wants to touch and a migration nobody wants to own.
Meanwhile the surrounding toolchain has moved. Modern CI systems, code review platforms, security scanners, dependency bots and GitOps controllers all assume Git. Staying on SVN increasingly means writing bespoke glue for each of them, and that glue is more expensive every year than the migration it postpones.
The risk sits in the middle. A migration done badly loses branch and tag structure, flattens author identity into a single unknown user, drags twenty gigabytes of build artefacts into every future clone, or ships with no answer for the binary assets that were protected by locks. A migration done well converts history faithfully, keeps the old repository as a verifiable read-only archive, and retrains the team on the workflow that replaces what they lost. The gap between those two outcomes is entirely skill.
A fast, honest baseline for the estate you have inherited. The client work cycle, what a working copy contains, why mixed revisions exist, and the handful of commands that cause most self-inflicted damage. Deliberately compressed — this module exists to make everyone accurate, not to make anyone an SVN expert.
Topics: The repository, the working copy and global revision numbers · The commit cycle: update, change, review, resolve, commit · Mixed-revision working copies and why status output surprises people · Conflicts and tree conflicts · svn revert, svn cleanup and recovering an interrupted operation · The commands that damage history and their safe alternatives
The conceptual core of the whole engagement. Each SVN mechanism examined for whether Git has an equivalent, a workaround, or nothing at all: branches as directory copies, svn:mergeinfo, locks on unmergeable files, externals, partial checkouts, path-based authorisation and the global revision number. Getting this wrong is why migrations regress.
Topics: Branches and tags as server-side copies versus Git refs · svn:mergeinfo versus Git's commit graph · Locking and svn:needs-lock versus Git LFS file locking · svn:externals versus submodules, subtrees and package managers · Sparse checkouts versus partial clone and sparse-checkout · Path-based authorisation versus repository splitting and code owners · Global revision numbers versus commit hashes and tags · Centralised commit access versus distributed commit plus review
Migrations fail in the audit that nobody ran. Inventory the repositories, measure size and binary weight, find the branches that were never under trunk/branches/tags, list the authors and match them to real identities, and identify history that is too damaged or too large to carry across unchanged.
Topics: Repository inventory and ownership · Detecting non-standard layouts and mid-history restructures · Measuring repository size, revision count and binary weight · Finding dead branches and abandoned tags · Extracting the author list and building an identity map · Detecting inconsistent or damaged mergeinfo · Externals inventory and what each one points at · Deciding history depth: full, truncated or archived
Doing the conversion, repeatedly, until it is boring. git-svn for incremental and bridged conversions, svn2git for one-shot conversions of standard layouts, and the handling that non-standard layouts demand. Then the cleanup that decides how the repository feels for the next decade: stripping build artefacts, converting large binaries to Git LFS, and rewriting paths.
Topics: git svn clone with --stdlayout, and what it does per branch · Handling non-standard and mid-history-changed layouts · svn2git and one-shot conversions · Applying the authors map and fixing identity after the fact · Converting branches and tags into real Git refs · Removing build artefacts and oversized blobs from converted history · Moving binary assets to Git LFS · Incremental fetch: keeping a converted mirror current during a long migration · Verifying a conversion by comparing trees at known revisions
The migration is a release, so it gets release discipline. Planning a freeze window, running a final incremental sync, redirecting CI and downstream tooling, and keeping the old repository as a verifiable read-only archive rather than deleting it. Plus the coexistence period some teams cannot avoid, and how to bound it.
Topics: Freeze windows and communication · Final incremental sync and the point of no return · Bidirectional coexistence with git svn dcommit and its limits · Making the SVN repository read-only and preserving it as an archive · Answering audit questions against an archived repository · Redirecting CI, release tooling and defect tracker links · Preserving revision-number traceability in the new world · Verification checklist and rollback position
The migration is not finished when the conversion lands; it is finished when the team stops working like it is still on SVN. Choosing a branching strategy, replacing commit-time hook policy with review and CI checks, replacing path-based authorisation with repository and permission design, and handling the binary and asset workflows that locking used to cover.
Topics: Choosing a branching strategy for a team leaving centralised VCS · Replacing pre-commit hook policy with pull request checks and server-side rules · Protected branches, required reviews and code owners · Replacing path-based authorisation with repository boundaries and permissions · Binary and asset workflow with Git LFS file locking · Commit hygiene for people trained on one commit per day · The first-fortnight failure modes and how to pre-empt them · Measuring whether the migration actually took
Most migrations take longer than planned, so the old estate still has to be run properly. The condensed operations set: hooks, authorisation, dump and load, mirroring, backup that has actually been restored, and the maintenance that keeps a large repository responsive until the day it goes read-only.
Topics: Repository hooks and enforcing policy at commit time · Path-based authorisation and access file maintenance · svnadmin dump and load, and svndumpfilter for splitting · svnsync mirrors for read-only replicas · Backup strategy and restore testing · Disk space, dead transactions and FSFS packing · Server access over svnserve and Apache httpd · Diagnosing slow checkouts and commits on large repositories
We rebuild the agenda around the tools you actually run.
Request a custom agendaInventory a repository with a non-standard layout: find the branches created outside /branches, measure binary weight per path, extract the author list and flag the mergeinfo that is already inconsistent.
Take a real workflow that uses locks, externals and path-based authorisation, and design the Git replacement for each — including the one that has no clean equivalent.
Run a conversion with git-svn and again with svn2git, apply an authors map, turn SVN tag directories into annotated tags, then verify by diffing trees at five known revisions.
Remove build artefacts and oversized blobs from converted history, migrate binary assets to Git LFS, and measure clone time before and after.
Run a full cutover in the lab: freeze, final incremental sync, verification pass, CI redirection and read-only archive — then trigger a failure and execute the rollback.
Stand up the post-migration workflow — branch strategy, protection rules, review policy, LFS locking — and run a complete release through it, including a hotfix.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.