[GSOC]Interactive patch selection

[jack_zhang at sina.cn]

.sinamailpaper-0{cursor:text;}
.sinamailpaper-0 td,
.sinamailpaper-0 textarea,
.sinamailpaper-0 input,
.sinamailpaper-0 br,
.sinamailpaper-0 div,
.sinamailpaper-0 span{font-size:14px;font-family:"宋体",Verdana,Arial,Helvetica,sans-serif;line-height:1.5;}
.sinamailpaper-0 p{/**margin:0.2em auto;*/margin:0px;}
.sinamailpaper-0 img{border:0;}
.sinamailpaper-0 pre{white-space:normal;}
.sinamailpaper-0 form{margin:0;}
body{font-size:14px;}
p{margin:0px;}
Hi, everyone. As a GSOC volunteer and a Mercurial  user, I would like to choose "Interactive patch selection for commit/Mercurial Queues/record/import"[1.] as my GSOC project. Before applying, I would like to collect advice for my idea to enrich my application. Any comments are welcome!

1.the granularities to select changes with
RecordExtension  currently allows patch selection with hunk granularity. Hunk is not the best granularity, we can spread in two opposite direction: for the upper granularities, we can select folds, module/files, they are even the only feasible granularities for binary files as it makes no sense to select a binary content with granularity of hunk; for the lower granularities, we can select changes by line. Maybe granularities of functions and classes in a source code file can be adopted, however, the complexity will expand extremely, furthermore, considering binary files, as it makes no sense to select a binary content with granularity of hunk, folds, module/files will even be the only feasible granularities.
In each granularity, users can select the current part or skip the remain parts.

2.the process flow 
For commands and extensions that take changes, such as commit, MqExtension(Mercurial Queues) and import, a final patch can be got by select the changes in an interactive way in the granularity hierarchy mentioned above. If the final patch is the same as the initial patch, commands and extensions just act as usual. Otherwise, the initial patch should be kept, in special directory or even in memory if possible. Commands and extensions will act based on the final patch, then the working space will be restored according to the initial patch.

3.state of product
First, an extension will be provided to test. Second, the new feature will be added into the core code of Mercurial, i.e. as an --interactive mode for many of Mercurial's core commands. Third, some GUI tools need be developed to provide friendly use.
As a GSOC project, I think the first and the second are necessary, while the third is just optional and can be realised later.

Wish for your voice, thanks a lot!

sincerely
Jack Zhang

[1.]http://mercurial.selenic.com/wiki/SummerOfCode#Interactive_patch_selection_for_commit.2BAC8-Mercurial_Queues.2BAC8-record.2BAC8-import

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100409/5f2c796d/attachment.htm>