Private corporate batches, live online cohorts and 1-on-1 mentoring in centralised version control at repository scale — working copies, merge tracking, server configuration and repository administration — 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 Subversion as both a client workflow and a server estate: the working copy and mixed-revision model, properties and externals, locking for unmergeable binaries, and merge tracking through svn:mergeinfo including reintegration, subtree merges and cherry-picking. On the administration side he covers repository layout and hook policy, svnadmin, svnlook, svndumpfilter, svnrdump and svnsync, FSFS maintenance and packing, svnserve versus Apache httpd with mod_dav_svn, path-based authorisation, SASL and SSL, replication and restore-tested backup. Sessions run against live repositories and servers, including deliberately damaged ones.
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 Subversion that means a trainer who has run it in production — centralised version control at repository scale — working copies, merge tracking, server configuration and repository administration — 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 Subversion batchApache Subversion is a centralised version control system that tracks changes to files and directories over time. One repository holds the authoritative history; clients check out a working copy, edit it, and commit changes back. Every commit produces a new global revision number that applies to the whole repository, which is why an SVN revision is a meaningful, orderable label for the entire tree — something no per-file or per-branch scheme gives you.
Subversion versions directories as well as files, and that single design choice explains most of its behaviour. Branches and tags are not special objects; they are cheap server-side copies inside the repository, which is why the trunk/branches/tags layout is a convention rather than a feature. Properties attach metadata to versioned items — svn:ignore, svn:externals, svn:eol-style, svn:mime-type, svn:needs-lock — and merge tracking is itself recorded in a property, svn:mergeinfo. Subversion supports both concurrency models: copy-modify-merge for text, and lock-modify-unlock for binary assets that cannot be merged at all.
Operationally, Subversion is a server product. It runs over svnserve or as an Apache httpd module with mod_dav_svn, stores data in FSFS, and is administered with a real toolkit — svnadmin, svnlook, svndumpfilter, svnrdump and svnsync — plus hook scripts that enforce policy at commit time. Repository layout, path-based authorisation, replication and backup are the parts that decide whether an SVN estate stays healthy for a decade or becomes the thing nobody dares touch.
Subversion did not disappear when Git won the greenfield argument. It persists exactly where its properties still win: repositories holding tens of gigabytes of binary assets, regulated environments that require server-side path-based authorisation rather than all-or-nothing clone access, and long-lived product lines where a single monotonic revision number is embedded in build systems, defect trackers and audit trails.
That creates two kinds of demand, and both are underserved. The first is operational: someone has to run these repositories — hooks, path-based authorisation, mirrors, dump and load, FSFS packing, backup that actually restores. The people who set them up have frequently moved on, and the knowledge went with them. The second is migration: moving history to Git without losing branch and tag structure, author identity, or the ability to answer an audit question about revision 41,207.
There is also a correctness dimension. Merge tracking, peg versus operative revisions, reintegration and subtree mergeinfo are genuinely subtle, and teams that treat Subversion as 'Git with worse commands' generate history that later resists both merging and migration.
What Subversion is, where it fits, and an honest answer to whether it is the right tool for a given repository. Then the core concepts: the repository and its global revisions, how a working copy actually works, mixed-revision working copies, and the two concurrency models — lock-modify-unlock and copy-modify-merge — with the file types that force each one.
Topics: What is Subversion, and is it the right tool · Subversion's history, architecture and components · Version control basics: the repository and the working copy · The problem of file sharing · The lock-modify-unlock solution · The copy-modify-merge solution · Revisions and addressing the repository · How the working copy works and its administrative area · Mixed-revision working copies and what they explain
Getting data in and working with it day to day. Importing an existing tree, the recommended trunk/branches/tags layout and why it is only a convention, checking out, and then the complete cycle: update, change, review, fix, resolve, commit — including the interactive conflict resolver and every way to discard a change.
Topics: Importing files and directories · Recommended repository layout: trunk, branches, tags · Creating a working copy · Update, make changes, review changes · Fixing mistakes and reverting · Resolving conflicts interactively · Postponing conflict resolution and merging by hand · Discarding changes in favour of a fetched revision · Committing changes and writing log messages
Reading what the repository knows. Diffing a working copy against the repository and any two revisions, generating change lists with svn log, browsing the repository without a checkout, line-by-line attribution with blame, and fetching older snapshots. Then the housekeeping side: cleanup after an interruption, disposing of a working copy, and structural tree conflicts.
Topics: Examining local changes and comparing to the repository · Comparing repository revisions · Generating a list of historical changes with svn log · Browsing the repository: svn cat, svn list · Line-by-line attribution with svn blame · Fetching older repository snapshots · svn cleanup and recovering from an interruption · Disposing of a working copy · Dealing with structural and tree conflicts
The two areas that cause silent wrong answers. Revision keywords and date-based revisions, then peg versus operative revisions — the mechanism that decides which object a command is talking about when a path has been moved or deleted. Then properties: why they exist, how to manipulate them, automatic property setting, and the standard properties that control portability.
Topics: Revision specifiers, keywords and dates · Peg and operative revisions · Why properties exist and how to manipulate them · Properties and the Subversion workflow · Automatic property setting · File portability: content type, executability, end-of-line sequences · Ignoring unversioned items with svn:ignore · Keyword substitution
The features teams either never discover or misuse. Locking for unmergeable binaries — creating, discovering, breaking and stealing locks, and communicating intent with svn:needs-lock. Externals for composing a working copy from several repositories. Changelists for organising work within one working copy. Then the network model and credential caching, which is where most authentication confusion originates.
Topics: Creating, discovering, breaking and stealing locks · Lock communication and svn:needs-lock · Externals definitions and their pitfalls · Creating and modifying changelists · Changelists as operation filters, and their limitations · The network model: requests and responses · Client credentials and credential caching · Disabling password caching and removing cached credentials · Command-line authentication
What a branch really is in Subversion — a cheap server-side copy — and what follows from that. Creating and working on a branch, the key concepts behind branching, basic merging and changesets, keeping a branch in sync with trunk, reintegration, and the mergeinfo property that makes merge tracking work. Plus undoing changes and resurrecting deleted items.
Topics: What is a branch in Subversion · Creating a branch and working with it · The key concepts behind branching · Basic merging and changesets · Keeping a branch in sync with trunk · Subtree merges and subtree mergeinfo · Reintegrating a branch · Mergeinfo and merge previews · Undoing changes with a reverse merge · Resurrecting deleted items
The merge behaviour that separates a healthy repository from a damaged one. Cherry-picking specific changesets, the full merge syntax, merges without mergeinfo, blocking changes you never want merged, keeping a reintegrated branch alive, merge-sensitive logs and annotations, ancestry, and the interaction between merges and moves.
Topics: Cherry-picking individual changesets · Merge syntax in full · Merges without mergeinfo · Merge conflicts in depth · Blocking changes from being merged · Keeping a reintegrated branch alive · Merge-sensitive logs and annotations · Noticing or ignoring ancestry · Merges and moves · Preventing naive clients from committing merges
Structuring a repository so it is still comprehensible years later. Simple and complex tags, branch maintenance and data lifetimes, and the standard patterns — release branches, feature branches and vendor branches — including the vendor branch procedure and svn_load_dirs.pl. Then the question teams should ask more often: whether to branch at all.
Topics: Creating simple and complex tags · Branch maintenance and data lifetimes · Repository layout decisions: one repository or many · Release branches · Feature branches · Vendor branches and the general management procedure · svn_load_dirs.pl · To branch or not to branch · Traversing branches with svn switch
Running the repository rather than using it. Deployment strategies, planning repository organisation, choosing where to host, and the data store decision — FSFS in practice, Berkeley DB where it survives. Then creating and configuring repositories, implementing hooks, and the administrator's toolkit that does the real work.
Topics: Strategies for repository deployment · Planning repository organisation · Choosing a data store: FSFS and Berkeley DB · Creating and configuring a repository · Implementing repository hooks · svnadmin and svnlook · svndumpfilter, svnrdump and svnsync · FSFS configuration and fsfs-reshard · Commit log message correction · Managing disk space, removing dead transactions and packing FSFS · Berkeley DB recovery and logfile purging
Moving repository data and keeping a copy that actually restores. Dump and load with svnadmin, remote dumps with svnrdump, filtering history with svndumpfilter, full and partial replication with svnsync, mirror creation, UUID management, and moving or removing repositories without breaking every working copy in the organisation.
Topics: Repository data migration with svnadmin dump and load · Migration using svnrdump · Filtering repository history with svndumpfilter · Replication with svnsync · Partial replication and a quick trick for mirror creation · Repository backup: full, incremental and hot copy · Managing repository UUIDs · Moving and removing repositories · Restore testing and what a backup is worth without it
Both server options, configured properly. svnserve as a daemon, under inetd, over an SSH tunnel, as a Windows service or a launchd job, with built-in authentication or SASL. Then httpd with mod_dav_svn: basic and digest authentication, blanket and per-directory authorisation, SSL for both server and client certificates, repository browsing, logging and write-through proxying. Ending with path-based authorisation, which is the reason many organisations chose Subversion in the first place.
Topics: Choosing a server configuration · svnserve as daemon, via inetd, over a tunnel, as a Windows service · Built-in authentication and access control files · svnserve with SASL: authentication and encryption · SSH tunnelling and SSH configuration tricks · httpd prerequisites and basic Apache configuration · Basic and digest authentication · Blanket and per-directory authorisation · Protecting traffic with SSL and managing client certificates · Repository browsing and Apache logging · Write-through proxying · Path-based authorisation and high-level logging
Keeping a large estate fast, and planning what happens next. Server optimisation, data caching, network compression and supporting multiple repository access methods at once. Then the strategic question every Subversion estate eventually faces: coexistence with Git, what git-svn can and cannot do, and how to convert history without losing branches, tags or author identity.
Topics: Server optimisation and data caching · Network compression of data · Supporting multiple repository access methods · Diagnosing slow checkouts, updates and commits · Coexistence with Git using git-svn · History conversion: branch, tag and author mapping · Handling large binaries during a migration · Deciding what history to keep and what to archive · Cutover planning and freeze windows
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a working copy that is deliberately at three different revisions, then retrieve content from a path that has since been renamed and deleted — the exercise that makes peg versus operative revisions click.
Configure MIME types, executability, EOL style, ignores and keyword substitution across a cross-platform codebase, then enforce them with automatic property setting and a pre-commit hook.
Run a feature branch through two sync merges and a reintegration, then cherry-pick two fixes onto a release branch and read the resulting svn:mergeinfo on every affected subtree.
Take a repository containing two products, split it into two with history preserved for each, then reload, verify revision mapping and reset UUIDs correctly.
Serve one repository over svnserve with SASL and over Apache httpd with mod_dav_svn and SSL, then implement the same path-based access rules on both and test them from a client.
Build an svnsync mirror, restore the repository into a clean server from backup, then run a dry-run conversion to Git with an authors map and verify branches and tags landed correctly.
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
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.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
| 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.