>
>
>
> As Branko already said, work is being done for this, as we speak. So if
> you're interested and want to share your ideas about how this should work
> in Subversion, hop over to dev@ and give your thoughts. There are some
> google docs written by Julian Foad with design ideas, UI proposal etc, for
> 'shelving' and 'checkpointing' (which may be a first step towards local
> commits). Just search the dev@ archives for the last couple of weeks ...
> input welcome.
>
>
Google's Perforce usage (before "Piper") is relevant. Why? Because back in
2000, Perforce was one of the VCS techs that Subversion sought to ape the
features of.
Perforce in 2006, didn't have local branching or a code review mechanism.
Google, centrally, rolled out "Mondrian" in order to do code reviews.
Effectively that system, at the moment the code review was sought, would
reach into your dev workstation and pluck out a tar.gz of the change-set to
a central system. Once there code review could begin.
This 2006 video shows that UI - https://www.youtube.com/watch?v=CKjRt48rZGk.
This would ultimately act as a gate. Specifically, developers would have to
pass code review before doing 'p4 submit' to push changes back to trunk
(Google do Trunk-Based Development). Perforce like Subversion *does not*
have a push-pull bottleneck (Git and Mercurial do) so the rate at which a
large team can submit/commit/push onto HEAD can be one a second (ore maybe
more).
In 2007 some Googlers started working on a Git local-branch capability for
their Perforce capability. It'd still be Trunk-Based Development for the
stuff that colleagues would see, but Googlers could have local private
branches. They could flip between a feature request and a bug fix casually
using Git as it was at the time. They could still enter code review - even
for two or more alternate commits to HEAD of trunk. A decent subset of the
staff used it, and were happy. Later Git gained a Perforce integration for
everyone else to use.
What Googlers didn't do (as far as I can recall - I left in Jan 2009) was
push those multiple local branch to a remote branch for others to depend
on. At least, not with Perforce being part of that. Now, the same
alternate change-sets being reviewed in Mondrian could be brought down to a
another developers workstation (to be improved, fixed, taken over), but
that wasn't a branch in Perforce - not remote and not local. Google's
tooling around Perforce was to augment their love of Trunk-Based
Development, their wish to have all* source in a monorepo, and to have
Build etc tooling that could casually reach any corner of that gigantic
source tree (9 million files at HEAD revision by 2015).
TL;DR. Code review is the gaping hole in Subversion. Subversion has had
perfectly functional local branches for seven years with Git-Svn.
- Paul
* not quite all source, Android is elsewhere. Back then Wave too.
Received on 2017-07-22 12:37:31 CEST