RFC: supporting code review and partial commits better

Robert Collins robertc at robertcollins.net
Thu Jul 17 11:53:51 BST 2008


On Thu, 2008-07-17 at 11:26 +0100, James Westby wrote:
> 
> For the case you mention at the end of the desire to have locally
> modified files that will not be committed resetting the marks
> on commit will be annoying. Is there a way we can improve this?

I don't understand - the use case I mentioned was to have no files be
selected by default, so you need to explicitly select files to edit. Do
you mean 'after committing something I had selected I probably still
want it tagged' ?  In which case, if commit always resets to [selected],
rather than to an abitrary default, this would be satisfied.

> My immediate thought would be a way to say "the default mark
> of these files is do-not-commit", so it seems like a file property,
> this seems to fit in with some of the work Ian has been doing.

Ian's work gets committed to history, which does not fit with the needs
of this at all. Its also in the working tree, which would cause special
cases in the code. Finally its geared for files and directories - I want
something much more granular; and hooked deep into iteration and
selection logic of dirstate, so that filtering directories recursively
by marks etc works well. But thats implementation :)

> > 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.
> 
> This use didn't come up yesterday, so it's good to see that the system
> is useful, and we can get some extra mileage out of it.
> 
> I'm interested in feedback from others, does anyone see any problems
> with this? Would it work for what you want to get out of bzr? Any
> other uses that it could be put to?
> 
> Idea #176 we had while talking about this: make a test runner that
> uses coverage information to add a "fails-tests" mark on any modified
> hunk that is exercised during the run of a failing test cases, so
> that "bzr diff -M=fails-tests" shows those changes implicated in
> the problem.

There were two cool ideas here - one was coverage -> mark the regions
covered; and tests -> mark the things failing. Combining them should be
pretty powerful :)

-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/20080717/57810f7e/attachment.pgp 


More information about the bazaar mailing list