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

Re: Subversion Design Contribution Question

From: Paul Hammant <paul_at_hammant.org>
Date: Wed, 1 Nov 2017 04:37:15 -0400

I'm also interested in standardized server-side handling of such things for
a different reason to the one you state - code reviews. Well outside the
purview of vanilla Subversion for sure, but a feature that the portal
vendors have or are coding themselves. I've a love of Trunk-Based
Development and got to see the code review system that Google built for
themselves around Perforce (Subversion was partially inspired by Perforce
back in 2000). Developers at their workstations would declare 'done', and
initiate code review. The changelist and some metainfo would be zipped up
and pulled to somewhere central. The bulk of the workflow is in the UI
Guido Van Rossum led at Google and showcases in
https://www.youtube.com/watch?v=sMql3Di4Kgc (2006). Post code review (and
CI added metrics) the change-list could be reconstituted and committed
(submitted in Perforce lang). It is the humble little save point that
facilitates the 25,000 developers co-existing in one trunk with Piper
(their 2012 replacement to Perforce) and ultimately bots integrating
(Martin Fowler's preferred language for merge to trunk/master/mainline when
practicing CI) change sets ever few seconds.

I'm much less interested in workflows where I'm sharing something by that
mechanism for others to work on, as that's not Trunk-Based Development.

Received on 2017-11-01 09:37:21 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.