[GSOC]Interactive patch selection

Nicolas Dumazet nicdumz at gmail.com
Fri Apr 9 01:30:58 CDT 2010


Hello!

2010/4/9  <jack_zhang at sina.cn>:
> 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.

Have you read http://mercurial.selenic.com/wiki/RecordExtension ?
There's a relevant discussion overthere. CRecord Extension, in
particular, already contains the code you would be looking for.


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

I would disagree with the idea of creating yet another extension. In
my opinion, you should be trying to include those changes in the
Record extension, possibly by extending its configuration.

I might like the --interactive suggestion. Could you expand on where
exactly it would be introduced? For which command?

>
> 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
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>



-- 
Nicolas Dumazet — NicDumZ


More information about the Mercurial-devel mailing list