RFC: supporting code review and partial commits better

[Robert Collins]

On Fri, 2008-07-18 at 23:50 +1000, Ian Clatworthy wrote:
> 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.

No worries...

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

So, I think the git index is really radically different to this; even
though people _use_ it to do reviews its mechanism, and thus its
behaviour, are quite confusing.

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

Possibly. I suspect they are really quite orthogonal: but I may be
wrong.

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

Ok

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

Re using update, I think it would be annoying to have to merge something
(which update implicitly does) to stop having some files on disk, or to
add existing ones.

I'm very pro minimising the default impact on the system, to avoid
making views/marks something that people need to learn to cope with a
tree that happens to be using them. (Obviously reducing the 'selected'
mark would impact all operations by default). I think views are
inherently going to affect people quite dramatically - which is by
design :).

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

Indeed.

So we've talked around this. The key difference between 'marks' and
'views' appears to be that marks alter what operations /show/, views
alter what is /put on disk/. So viewing only the bottom half of a file
is pretty hard to implement. But viewing a file in a directory is
sensible.

We can sensibly have the view metadata managed by the same system that
manages marks; we just need to make sure that:
 - the mark representing views is never specified at the hunk level
 - the mark representing views always propogates up parents

I don't think that there is much in common in the rest of the system -
for instance, merge with views needs to only consult the dirstate for
many files, merge with marks will always merge the same as merge without
marks (because marks never affect what is put on disk).

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

:) Indeed!

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20080719/8f0a5336/attachment.pgp