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

Re: Tree conflict 'svn merge' message

From: Paul Hammant <paul_at_hammant.org>
Date: Sat, 30 Dec 2017 12:26:37 -0500

Here's one from the past - https://issues.apache.org/jira/browse/SVN-3495

- A famous airline was the client back then and they were strangling their
older (but accomplished) cgi-bin/C++ stack. We were doing concurrent
development of consecutive releases. Different teams from two consultancies
(ThoughtWorks and Globant) were working on different branches, and about
four major releases were being developed at the same time. Each "following"
release team was supposed to merge the prior release teams weekly changes.
A cascade branching model. We tried to hunt around for someone to fix that
big for hard cash, but could not.

We hacked our way through it at the time, and a couple of months later
moved every one to Trunk-Based Development (including a love of build
flags, and boot flags). Flags are 'toggles' in Martin Fowler's lexicon.
Branch by Abstraction figured too, as did a lot of Jenkins infrastructure
and a policy of rolling back commits if they broke in any of the pipelines
that Jenkins was running in parallel. Builds were still batches of commits
though, a we didn't have the infra to run one build per commit. We (I) had
put too much Selenium tests in the pipeline and they really took a while
(even if run parallelized). It wasn't a patch on Google's per-commit fu
though. Oh, with Trunk-Based Development (and flags and
branch-by-abstraction) we were never going to have a merge conflict again,
of course.

- Paul
Received on 2017-12-30 18:26:48 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.