Differences between revisions 9 and 10
Revision 9 as of 2014-02-17 18:14:18
Size: 4876
Comment: link to candidate checklist.
Revision 10 as of 2014-02-27 20:36:04
Size: 4459
Comment: Progress Bar is too little, Web search has been done by durin42 (but has to be found somewhere)
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:

== Progress bar improvement ==

The [[ProgressExtension]] offers a progress bar for some Mercurial commands, but its accuracy can be improved by mean of a better weighting algorithm.

== Searching support for the help in the web UI ==

It would be desirable for the Mercurial web interface [[PublishingRepositories#hgweb|hgweb]] to have an integrated search functionality to the [[ManPages|Mercurial help]].

GSoC Project Ideas for 2014

Here are some ideas of possible 2014 summer project ideas for Mercurial. Your own ideas are welcome. You may decide to work on these ideas or use them as a starting point for your own.

/!\ All potential GSoC candidates should visit our SummerOfCode/2014 page

1. Implement Consensus Merge

See ConsensusMerge. This project will require a candidate who's pre-demonstrated some ability with the merge code.

2. Advanced revset optimization

Revsets are a powerful built-in query language for looking at changesets. We even have an optimizing engine to reorder queries for performance. But there are several areas where things could be improved:

  • incremental, generator-style evaluation (already in progress)
  • cache/avoid repeated evaluation of common subexpressions
  • efficient handling of very large contiguous ranges

3. Unicode filename support on Windows

While Mercurial users on Linux and Mac can happily exchange repositories with filenames in Unicode and even legacy encodings, Windows presents some extra challenges for using non-ASCII filenames portably. We'd like to address this by introducing an automatic UTF-8 translation layer on Windows systems.

See WindowsUTF8Plan

4. Generic templating support

Mercurial has a powerful templating engine, but on the command line it's only available for log-like commands. We'd like to extend its power and flexibility to the rest of Mercurial's command-line interface, in addition to adding built-in support for standard formats like XML, JSON, etc.

See GenericTemplatingPlan

5. Improved built-in help

Mercurial's built-in help is quite good, but could be better. Here are some things that could be done:

  • improve crosslinking between help topics
  • migrate remaining contents from manpages into built-in help
  • add example usage to verbose sections in help
  • improve the glossary

6. Performance tuning

Mercurial is fast but could always be faster. Possible areas include:

  • Optimizing startup performance
  • Optimizing performance on Windows

7. Improvement of the testing tool and testing annotation

Mercurial have very powerful testing tools. However as the amount of test grows bigger and bigger managing all those tests becomes hairy.

Every test-file usually holds multiple sections that each test a small set of features. If we had an official way to document and annotate those section the test-suite would be more easy to maintains. This project includes the following tasks:

  • Definition of an annotation format,
  • Improvement of the failure report,
  • Declaration and use of dependency between section,
  • Test timing report.
  • Generation of nice html page from the test and to be linked from relevant help page.

8. obsolescence support in graphlog and hgweb

Recent version of Mercurial support the ChangesetEvolution feature. But neither log (including --graph) not hgweb show relation between precursors and successors changesets. The goal of this project is to add support to display information related to ChangesetEvolution those commands:

  • Add successors and precursors data in hg log (when applicable)
  • Add obsolescence edge in hg log --graph
  • Add obsolescence edge in hgweb
  • Add a way for hgweb to show obsoleted changeset.

9. integrate in TortoiseHg tools to compare branches from different repos

Currently TortoiseHg can inspect only branches that belong to the same repository. For instance, it is not easy to tell at which changeset two branches have diverged, if those two are stored in two separate repos. Nonetheless it is not uncommon for a group of developers to wander in what relation are their repositories/branches between each other. The version control system Bazaar have this feature, and it is very appealing: multiple branches are shown together in a single directed acyclic graph, possibly with multiple heads, no matter where the repository come from. This blog post gives an illustration of what a similar feature can look like: http://www.gghh.name/dibtp/?p=361

This project aims to provide TortoiseHg with the aforementioned capability. This changeset provides already a possible starting point: http://selenic.com/hg/rev/a9c443b3b240

10. Other ideas?

Come talk to us on IRC.


CategoryGsoc

SummerOfCode/Ideas2014 (last edited 2014-04-29 11:19:56 by gidyn)