GSoC Student Guidance and Project Ideas for 2018

Please see also our SummerOfCode/2018 page, which contains additional information for GSoC for this year.

1. About Mercurial

• What is Mercurial? Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface.

• Why is it interesting? Besides the extremely good reasons just above, Mercurial is also interesting for many other reasons, including: a great extension system, excellent backwards compatibility, excellent documentation, ... Specifically for students, it's interesting because it offers a range of topics to work on from low-level speed optimizations all the way up to a web interface.

• Who uses it? Mercurial is used by individuals, organizations and companies all over the world. The same goes for contributors: in the open source community, a well-known organization using Mercurial is the Mozilla project, but companies like Facebook, Google and many others also contribute to Mercurial.

• What language is it written in? Mercurial is mostly written in Python. We rewrite some parts that are very performance-sensitive in C.

2. Contacting the Mercurial developers

The following channels are used by default for communication. Please use them to introduce yourself!

• IRC: many developers chat and discuss planned changes to Mercurial here. Keep in mind that most developers are in US timezones, so it might take quite a bit of time (hours) to get a response outside of those timezones!

• The developer mailing list: this list is mostly used to submit patches and discuss them.

3. Getting started/Candidate checklist

All candidates should do the following before completing their application:

1. Check the SummerOfCode/Ideas2018 page

2. Subscribe to this page to get email when it changes

3. Introduce yourself on IRC

4. Introduce yourself on the mailing list

5. Read the ContributingChanges pages.

6. Look at the easy bugs list and contribute a patch. Feel free to ask questions on IRC or the mailing list while getting started!

7. Follow the steps to apply: check the application checklist and submit your application.

4. Things we look for in a candidate

• Demonstrates understanding of our tools, procedures, and source code by successfully submitting patches (see last step above)
• Participates in the community, especially via IRC
• Makes a commitment to work on GSoC full-time
• Gives an indication that she or he enjoys working with Mercurial enough to become a long-term contributor, after GSoC is over.

5. GSoC ideas

Here are some ideas of possible 2018 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.

5.1. Example Project

• Project description: This is an example project. Please add a clear description with some details about the idea.

• Skills: Specific programming languages, domain-specific knowledge... For example: Python, network programming

• Difficulty level: Easy/Intermediate/Difficult

• Related reading/Links: Useful links to wiki pages, specific relevant mailing list discussions or patches, ...

• Further details: Additional detail about the idea

• Point of Contact: Who wrote this proposal and could answer question about it.

• Potential mentors: mentors likely to be involved with this project

5.2. Improve commit graph in hgweb

5.2.1. Project description

While hgweb is the web UI that comes together with Mercurial and so is readily available to every user, it somewhat lags behind in presentation. You can see an example of the current hgweb interface at the Mercurial's main repo.

This project focuses on graph rendering in hgweb, because seeing the DAG can be very useful and because there's plenty of ideas on how to improve it. We could make it faster and smarter, show more things, and look nicer. Here are some ideas, but not all of them are required, and more ideas can be added in the process if everyone agrees on them.

• Think up a good (extensible, self-descriptive) format for new graph data to put into JSON and implement it server-side
• Display special edges, such as source-destination of a graft and obsolescence relations
• Make graph more space-efficient (visually) and easier to understand by using different colors (there is color variation for different branches, but the algorithm can be improved and color variation can potentially be added to nodes too)
• Show faded-out edge(s) on screen top and bottom when there are more changesets available, to imply that the current view doesn't include all of the changesets

• Solve issue4020 either by splitting graph into multiple visual elements (<canvas> or <svg>), by sliding viewport or by other means

• Maybe use SVG instead of <canvas>, and add tooltips to some elements (e.g. graph nodes of unstable commits)

More ideas and visual decisions could be borrowed from TortoiseHg, Bitbucket and Kiln.

5.2.2. Project properties

• Skills: Python (server-side), JavaScript (client-side)

• Difficulty level: Intermediate (but can become more difficult if you can take up some of the more complicated subtasks)

• Related reading/Links: https://bz.mercurial-scm.org/show_bug.cgi?id=4020 https://bz.mercurial-scm.org/show_bug.cgi?id=2570 (not limited to these)

• Point of Contact: AntonShestakov (av6 on IRC)

• Potential mentors: Pulkit Goyal (pulkitg on IRC)

5.3. Add dry-run functionality to each commands

5.3.1. Project description

There are some write commands which have a --dry-run flag which tells user what will be the results of the operation without doing that. For example hg revert --dry-run.

This project focuses on adding the --dry-run flag to write commands which are good candidates like phase, strip, pull, push, amend, graft, merge, rebase, histedit. In case of rebase, histedit, graft, prints out the graph that would result if we ran the command.

Bonus points if we can have a --confirm flag too. Difference between --dry-run and --confirm:

• --dry-run means "show me what would happen without --dry-run and then throw all work away"
• --confirm means "show me what would happen, then ask me if we should do it or throw it out

5.3.2. Project properties

• Skills: Python

• Difficulty level: Intermediate (but can become more difficult if you can take up some of the more complicated subtasks)

• Point of Contact: Pulkit Goyal (pulkitg on IRC)

• Potential mentors: Kevin Bullock (TheMystic on IRC), Sean Farley (smf on IRC)

5.4. Improve the functionality of `hg grep`

5.4.1. Project description

This project aims to improve functionality of hg grep command. Right now behavior of the command is ambiguous, undocumented and not what people expect mostly. We need to improve the functionality of plain hg grep and hg grep --all. To see what both of them do right now, look for GrepPlan.

Here are some tasks which needs to be done as a part of the project:

• Make hg grep search all tracked files in the current working directory by default.

• For hg grep -r <rev>, search all tracked files in the given revision set

• Introduce a --diff option to hg grep which does exactly what hg grep --all does right now

• Deprecate the --all flag in favor of --diff.

• Document the new behavior. Should be done with each task completed.

• Fixing https://bz.mercurial-scm.org/show_bug.cgi?id=3885

For more information GrepPlan.

5.4.2. Project properties

• Skills: Python

• Difficulty level: Intermediate

• Related reading/Links: GrepPlan

• Point of Contact: JordiGH (JordiGH on IRC)

• Potential mentors: JordiGH (JordiGH on IRC), Pulkit Goyal (pulkitg on IRC)

6. Other ideas?

There are more things on WeShouldDoThat which we will like someone to work on. You can pick an idea from there too.

Come talk to us on IRC.

CategoryGsoc CategoryGsoc