GSoC Student Guidance and Project Ideas for 2019

Please see also our SummerOfCode/2019 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.

If you don't have a persistent internet connection, it is advised to email the developer list instead of IRC because it may take time to get a reply.

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 2019 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. Curses UI for annotate and other commands

5.2.1. Project description

How cool are the programs which interact with you, right?

In mercurial, we have an interactive curses interface which uses python curses module. Right now curses UI can be to select chunks to commit, revert, shelve and also do a histedit. This project is about using curses UI in more places like annotate.

Annotate is a command which shows history of each line in a file. Think of an UI, where you go to a line, hit back button, and go back to old version of that line. Select a commit and go back to the state of the file at that commit. Sounds very interesting right?

To get to this stage, we need to do the following:

• understand how python curses module works and how that is used in existing commands
• design a UI for annotate command which can be implemented using curses
• implement required API's in core mercurial to which curses API's can talk
• implement the curses interface for the command and add tests!

Although this will take good amount of time but in-case this turns out be easier, the project will involve implementing curses UI for other commands.

5.2.2. Project properties

• Skills: Python

• Difficulty level: Intermediate

• Related reading/Links: Python curses API

• Point of Contact: pulkitg on IRC

• Potential mentors: TBD

5.3. Add functionality to store an unresolved merge-state

5.3.1. Project description

Merge conflicts are painful. How about having a functionality where we can store an unresolved merge state? This will help us in doing other tasks if required at the moment in the same repository and also get back to the same merge state and resume resolving conflicts.

This project involves developing a functionality where an unresolved state can be stored in some way and can be restored in future. The commands which perform merge between two revisions like merge, graft, rebase, histedit, shelve can result in merge conflicts. For commands like rebase, histedit, we might need to store their state files too.

Also, pijul version control already does that. It let's you commit conflicts as conflicts and then you can solve them later or have someone else do that.

To get to this stage, we need to do the following:

• develop a plan with breaking the whole task into smaller sub-tasks. This will involve investigating how pijul does that
• think of an UI which can be used to store and restore merge-states
• Analyze what are the things which need to be stored and develop storage format for that
• Implement the support for basic command like merge
• Implement support for multi-step commands like rebase, histedit
• think about support for exchanging such data
• Add documentation and tests for every code you write!

Although this will take good amount of time but in-case this turns out be easier, other small tasks related to merge state and related things can be added.

5.3.2. Project properties

• Skills: Python

• Difficulty level: Intermediate

• Point of Contact: pulkitg on IRC

• Potential mentors: TBD

5.4. Rewrite config parser to add support for writing hgrc files from command line

5.4.1. Project description

In Mercurial we uses a set of configuration files to control aspects of its behavior. It depends on the path of a config file how it would behave for e.g. Local configuration which is inside a particular repository <repo>/.hg/hgrc will apply config options in current repository only or Global configuration $HOME/.hgrc which apply it's config option in every hg commands in any repository. To get detailed information about all the Mercurial configuration files and their syntax run hg help hgrc.

At present, if you want to update a config file you would have to edit the hgrc file manually. So the aim of this project is to adding a support where one can update/insert a config option in a particular config file just by running a command.

More details will be added soon.

To get to this stage, we need to do the following:

• understand how existing config parser doing things
• implement new methods or update existing one's in parser to add support for write/update in a config file
• add new command or flags which will be used to update config files from cli
• Add documentation and tests for every code you write!

5.4.2. Project properties

• Skills: Python

• Difficulty level: Intermediate

• Related reading/Links: Config parser for Mercurial

• Point of Contact: pulkitg on IRC

• Potential mentors: TBD

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