[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: Daniel J. Lacks, PhD <DannyL9143_at_aol.com>
Date: Thu, 2 Nov 2017 23:09:15 -0400

Sounds like a good idea Paul, something I did not think of.


On 11/1/2017 4:37 AM, Paul Hammant wrote:
> 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.
> -ph

This email has been checked for viruses by Avast antivirus software.
Received on 2017-11-03 04:09:06 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.