Re: Subversion Design Contribution Question

[Paul Hammant <pa...@hammant.org>]

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

Re: Subversion Design Contribution Question

["Daniel J. Lacks, PhD" <Da...@aol.com>]

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


Danny


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.
https://www.avast.com/antivirus