RFC: supporting code review and partial commits better

[Robert Collins]

Some percolated thoughts:

 - using an actual staging area seems liable to drive skew between what
is committed and what is marked

 - mv/add/delete/shelve all want to work with marks

 - merge and all merge derivatives (e.g. pull, revert) want to preserve
marks

 - we might want a marks namespace to separate out arbitrary user marks
and marks for views etc. OTOH having a flatnamespace with some blessed
tags allows users to choose to drive things in unexpected ways; for
unversioned data this seems to work quite well.

 - when a marked region is changed should the mark be preserved? (I say
yes - in the review sense the reviewer knows they changed something).
The only issue is when the marked region becomes ambiguous and bzr might
then have to ask/show something in status.

 - we could implement a decorator approach (get a MarkedTree(WT,
['selected', 'reviewed'])), or a integrated
approach(WT.select_active_marks(['selected', 'reviewed'])
   because commit and merge will modify a tree with marks (commit
changes the parents list and resets marks, merge updates marks to track
merges) I'm leaning strongly towards an integrated approach.

 - I'm thinking of tracking hunks by using sequence matcher information
or something roughly similar to identify a hunk, so that a new hunk
before it doesn't throw the marks off, and ideally so that hunks joining
is handled gracefully.

I've done a number of hallway-description-tests of this concept, and so
far its been overwhelmingly positive.

It would be nice to make the implementation one that can be used by bb
and launchpad's code review systems too.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080722/f4fc1c4e/attachment.pgp