[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What comes after 1.12?

From: Paul Hammant <paul_at_hammant.org>
Date: Tue, 20 Aug 2019 19:50:36 +0100

My DevOps consulting life (around how to get to Trunk-Based Development
from some often ClearCase inspired branching model), starts with what
release cadence are you at now, and what do you want to get to. Clients
who are quartly want to get to monthly (and have less unplanned releases
following each). Clients that are monthly want to get to weekly (same
elimination on unplanned). Aaand clients that are weekky eye daily. Sure
that's dev teams of 20-1000 in one repo, where change would firehose into
the repo if it could,

*I've not encountered an enterprise team that wanted to slow down release

Seems to me Svn's problems are 1) lack of committers, perhaps because 2)
patch contributors don't feel it matches their smoother experience
elsewhere, and because 3) running "the build" from zero is hard, and 4)
tests in the build isn't a super uniform thing.

If you all developed on trunk (patchsets for trunk, or direct to it), and
had an automated CI build setup that tested all permutations in parallel,
and a merging bot that attempted to cherry-pick commits marked as [BUGFIX]
back to all supported release branches without human intervention (and
Apache-TM votes), then you might have streamlined things. Such a bot
shouldn't shit the bed if the cherry-pick fails *

Of course you're stymied by a lack of a integrated patch consumption
technology. Gerrit and Rietveld were made in Mondrian's image, ten years
ago. That said GitHub and pull requests a few months later stole the
spotlight and have not relinquished it since. Julian's stash/shelve tech
is the start of a standardized Pull-Request system for Svn, but the vision
need to be expanded.

Meanwhile, Mononoke ** is pushing forward to monorepo-nirvana even if
Atlassian today declare that Mercurial support in BitBucket has an end

* oh, the back-applying merge bot will work fine as long as no rename/move
refactorings happen in the Subversion tree. That's because Subversion can't
merge through rename (unlike Git and Mercurial - seamless). Perforce could
do it if you muck around with branch-specs, but nobody does.

** Mononoke (a Rust backend for Mercurial) is hosted on GitHub (Git). The
dev eam feels no shame from that, perhaps because it's a periodical copy
from the same source-tree inside Facebook (and isn't currently buildable).
Git made a Svn compatibility for GitHub's Git repos - I wonder if future
contributors to Mononoke could too. Repo:
Received on 2019-08-20 20:50:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.