> > > > 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.
