Details
We're currently trying out Arcanist and have the following itch holding up adoption:
If a differential revision is created for a bug fix, and accepted by the reviewer, the original creator must perform the wholly automatable task of getting a version of the local copy with that revision applied and running "arc commit" on SVN. This can be unnecessarily problematic if the developer has already moved onto another development task and does not have a clean working copy.
Firstly, how does Arcanist handle the subsequent local mods? Will it apply a patch over local mods and svn commit only the modifications listed under that revision? What if there are conflicts?
Secondly, is there a way to automate the svn commit for these special bug fixes large enough to warrant a review but small enough that the extra overhead of the final "arc commit" becomes significant? This can be automated in other ways, but there are concerns for author corruption etc. @epriestley (Cheeky bump!)
Answers
At Facebook, I solved this by simulating local branching using multiple SVN working copies. For example, I would develop a change like feature1 as:
$ svn checkout svn+ssh://.../ feature1 $ cd feature1 $ nano some_file.php $ arc diff $ ... $ arc commit
During the ... part, I could perform unrelated work in adjacent working copies (feature2, feature3), etc.
The biggest issue with this workflow was that the initial checkout took a while. To handle that, I wrote a script which kept an unused checkout on disk, and would just copy it over and do svn up, then start a new checkout in the background. This got the cost of "branching" down to a few seconds in most cases.
Most other engineers solved this problem by switching to Git, and using git-svn to bridge Git to SVN. This let them do local branching in git without requiring the backend to migrate away from SVN.
Prior to git-svn, a popular approach was just to work on unrelated things in the same working copy. arc has some protections which try to limit the damage this will cause -- notably, svn commit will commit only the affected files listed in the revision. This will sort of let you develop unrelated changes at the same time in the same working copy. However, it can't do anything if there are changes to the same files, and can't detect or warn you about this, and this is generally a bad idea for a variety of other reasons.
We have some support for a "Land This" button (see T182), although it doesn't yet handle SVN and doesn't work well in general yet. This will come to the UI and work in general eventually, but it won't be able to do anything reasonable in the case of conflicts, so it will only reduce the frequency with which this problem occurs. It can't do anything in the case where a reviewer rejects changes and the author needs to make adjustments either.
Basically, approaches I've seen are:
- simulate local branching with multiple working copies;
- simulate git stash with some kind of script for shuffling diffs around;
- use git over git-svn;
- roll the dice and develop unrelated changes in the same working copy;
- T182 will eventually mitigate some of this, but probably more like 60% than 95%.