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

2. Contacting the Mercurial developers

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

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

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

5.2. Improve commit graph in hgweb

5.2.1. Project description

Used Github, Gitlab, Bitbucket or other code hosting platforms and got interested how things are working there. Well this project is for you then!

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. One can run their own hgweb server using hg serve command. As you can see, in the today's world where we nice styled components using react, hgweb looks like a 2010 website.

This project focuses on improving 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.

We can borrow more ideas from existing code hosting platforms such as Github, Gitlab, Bitbucket, Kiln, RhodeCode etc.

5.2.2. Project properties

5.3. Curses UI for annotate and other commands

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

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.3.2. Project properties

5.4. Add functionality to store an unresolved merge-state

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

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.4.2. Project properties

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

SummerOfCode/Ideas2019 (last edited 2019-02-11 21:12:35 by PulkitGoyal)