RFC: supporting code review and partial commits better

[Ian Clatworthy]

Robert Collins wrote:
> This is about a feature we're missing; how to do it tastefully from the
> UI, and possibly some implementation thoughts. Jelmer, James Westby,
> Daniel Watkins and I are sprinting in London - we've sketched some very
> high level concepts - please read this and give us feedback!

Guys,

Sorry for the delayed feedback - only just got to this thread.

> Now, how would this hang together. Firstly, there is a new concept of
> marks on the working tree state. Our current working trees are
> equivalent to a '/':[selected] tag. That is, everything in a working
> tree is tagged selected. By default diff, status, commit, will only
> operate on selected content. Using the -M (or --Marked) option to
> diff/status/commit will cause the diff to only include tags matching.
> E.g. diff -t=-selected is (diff everything that is not selected). diff
> -M=reviewed is 'diff reviewed changes only'. And diff -M=-reviewed is
> 'diff unreviewed changes'. because of the default of 'selected' applying
> to diff/status/commit, doing 'bzr status' and 'bzr diff' will always
> show you what commit will do. revert and commit will clear marks back to
> the default ([selected]).
> 
> bzr shelve could be integrated with this - 'bzr shelve -M=cruft
> --all' :).
> 
> This would give a really flexible system for managing complex merges -
> or even just complex sets of changes in your working tree. 
> 
> Partial commit (commit -i) can then be a two-phase operation - phase
> one, put up the mark editor for whatever the user requested to commit.
> E.g 'bzr commit -i -M=-reviewed' (commit interactive unreviewed
> changes). Mark with something like 'interactive-commit', then backend to
> commit -M=interactive-commit.
> 
> A further feature some folk request is the ability to specify that only
> some files are being edited. By having a configuration option to toggle
> the default mark from [selected] to [], commit, diff, status etc would
> all ignore all changes in the tree and need explicit instruction to
> examine a file. We could add to tree building operations a check for
> 'selected' in the taglist - and if its not present make the files
> readonly.

Assuming we can smooth out the UI and implementation challenges inherent
in such an advanced feature, I really like the sound of this. FWIW, I
was looking to add 'git index' like functionality as part of the filtered
views feature I'm been rambling about since the big London sprint. Please
read the design notes that I put up shortly after that sprint:
http://bazaar-vcs.org/FilteredViews.

In my case, I was tackling "partial checkouts + partial commits" where
your starting point looks like it was "better reviews + partial commits".
You therefore go down to the hunk level while I was just managing a
'view' of files. Hunk level is great and introduces lots more potential.
I was also starting with just one view where it sounds like you're
proposing multiple ones. Perhaps mine just becomes one of yours?

Here's a sketch of how I wanted 'filtered views' to work ...

  $bzr branch http://bzr.example.com/proj --view docs
  Branched 1234 revisions.
  Ignoring files outside view: docs/

This creates a branch proj but only populates the docs part of the WT.
./bzr/checkouts/view (say) would have one line containing 'docs/'.
status, diff, commit, revert & update would implicitly have 'docs/' as
the set of files unless overridden on the command line. Merging from
other branches would work, though conflicts outside the docs/
directory would get populated into the WT at that time.

To see the current view ...

  $bzr view
  Ignoring files outside view: docs/

The view would be adjustable. To change the view so that future
operations worked on just NEWS and tests/, the command would be ...

  $bzr view NEWS tests/
  Ignoring files outside view: NEWS tests/

To clear the view ...

  $bzr view --clear
  View cleared. Please update if files are missing in the working tree.

I was thinking that the view command ought to just set/clear the view
and that update would need to be specified separately. We could always
add an --update option to view to do both if desired.

So please incorporate something like the above into your plans. I
honestly can't see DVCS tools replacing CVS & Subversion at many projects
until 'give me a filtered branch/checkout' is available. Tech writers
and translators just want to see their 1% of mega-projects, not all
the code and other stuff. Having this for the OOo, GNOMEs and KDEs of
the world will win plenty of friends.

It is going to *so* rock to have 'index' functionality that Just Works
and is there only when wanted!

Ian C.