[GSOC] Interactive patch selection for commit/Mercurial Queues/record/import

[Justin Peng]

Hi ,all.

I've chosen ' Interactive patch selection for commit/Mercurial
Queues/record/import' as my project idea for this year's GSOC.  To get a
clearer knowledge about it before submitting my application, I 'm here to
ask for your comments and advice on it.


A. Citing description on the wiki page of SummerOfCode

'3.7. Interactive patch selection for commit/Mercurial Queues/record/import

Being able to select parts of the existing changes, with hunk or greater
granularity, in an interactive way, can improve the use of commands and
extensions that take changes, such as commit, MqExtension(Mercurial Queues)
and import. The RecordExtension currently allows patch hunk selection, but
sometimes a better granularity is desired, as when a set of adjacent
function definitions should go in different commits. This feature could be
added as an --interactive mode for many of Mercurial's core commands.'


B. My thinking about better granularity of selection.

IMO, the problem includes a set of granularities but not simply only one
optimal granularity in fact.

The set of granularities can be considered as a tree whose root is just 'all
changes of a project', and  be arranged in hierarchy as:

  changes of a project
   |
   |---- changes of a folder
          |
          |---- changes of a module/file
                    |
                    |---- changes of a hunk
                             |
                             |---- changes of a class in a hunk
                                    |
                                    |----changes of a function in a class

As the figure shows, changes in a hunk are the subtlest, as a hunk may be
divided into some elements such as classes or  functions, all the elements
should be able to process (commit or skip) respectively. For instance, after
adding  some new classes into a module in working directory, it's possible
to choose which classes, and which functions of those chosen classes to
commit, in an interactive way.

At any granularity, users can do 4 things:
1.) choose the current change unit.
2.) skip the current change unit.
3.) choose all change units left in the parent unit.
4.) skip all change units left in the parent unit of current change unit,
which leads to the next parent unit.
while the 3.) and 4.) can be extended recursively.


C. Apply the filtered patches

At present, 'RecordExtension[1]' provided by Bryan O'Sullivan has shown a
framework for interactive patch selection. It works following these steps:
1.) Get all changes to process
2.) Get a filtered patch in an interactive selection.
3.) Backup changed files, so we can restore them in the end.
4.) Clean the repo to the original state.
5.) Apply the chosen changes to the working directory.
6.) Do actual commit.
7.) Finally restore backed-up files
I think this workflow can perform well, and I plan to adopt it in my future
work, for extension on many of Mercurial's core commands.


D. Milestones

1. Collect requirement, it including:
1.) Define  the hierarchical set of granularities of selection,
2.) Define the collection of supported operation on each granularity.
3.) Define the collection of Mercurial's commands to support the new
'--interactive ' mode.
This work starts from now on, and hope it ends before May 23.

2. Implement the patch-filter function.
Hack the new filter on RecordExtension first, and insist on unit-test.
In the end of this phase, an improved RecordExtension should be given.
It's plan to end before mid of July.

3. Adapt core commands to support the new '--interactive ' mode.
It's plan to end before mid of August.



Wish for your advice. Thanks!
Regards
Justin Peng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090330/664373ff/attachment.htm