Size: 8429
Comment: add largefiles idea
|
Size: 8648
Comment: Start cleaning up and further extending project ideas
|
Deletions are marked like this. | Additions are marked like this. |
Line 54: | Line 54: |
=== Improved handling of merge conflicts === | |
Line 56: | Line 55: |
* '''Project description''': Improve the user-friendliness of merge conflicts. |
=== Moving toward Python3 === |
Line 59: | Line 57: |
Currently, a number of merge conflicts are not handled in a clean way. Rather than present the user with a number of ways to handle a conflict, Mercurial simply aborts. | ==== Project description ==== |
Line 61: | Line 59: |
One example of this is directory/file conflicts. This is the case where on one side of the merge, a file is created. On the other side of the merge, a directory with the same name is created. During a merge, an obscure error pops up. This should be handled properly, by allowing the user to choose how to handle the conflict. | Mercurial currently only supports Python 2. We'd like to improve Python3 support, but that will require a lot of work. A large amount of the work is relatively simple. Some of the first tasks needed will be: * Fixing the warnings in the Python3 compatibility test ([[https://selenic.com/repo/hg/file/default/tests/test-check-py3-compat.t|test-check-py3-compat.t]]). * Fix imports to use absolute_import across the code base. [[https://selenic.com/repo/hg/rev/68b9abf1cb82|Some]] [[https://selenic.com/repo/hg/rev/798535853345|examples]] [[https://selenic.com/repo/hg/rev/b1adf32b0605|of]] [[https://selenic.com/repo/hg/rev/a16489f9132d|this]] [[https://selenic.com/repo/hg/rev/e6d3dad71e44|work]] [[https://selenic.com/repo/hg/rev/071af8d385a9|are]] [[https://selenic.com/repo/hg/rev/ce3ae9ccd800|available]]. * Some of our modules don't yet parse in Python3. This needs to be fixed as well. * We currently use '''2to3''' to compile to Python3 bytecode. Rather than using this, we should unify our codebase to work in Python2 and Python3. * Some Python modules have different names or different properties in Python3. A compatibility layer (or conditional imports) will be necessary to handle these changes. Further (also more difficult) tasks are listed on the Python3 page, but the above will most likely take up quite a bit of time already. ==== Project properties |
Line 63: | Line 73: |
* '''Difficulty level''': Difficult (?) * '''Related reading/Links''': http://bz.mercurial-scm.org/show_bug.cgi?id=29 * '''Further details''': MergePlan contains more details about the exact problem and a possible path forward. Additionally, the [[https://selenic.com/repo/hg/file/default/mercurial/filemerge.py|filemerge code]] is most likely to be relevant. * '''Point of Contact''': |
* '''Difficulty level''': Easy * '''Related reading/Links''': [[Python3]] * '''Further details''': See [[Python3]]. * '''Point of Contact''': Greg Szorc, Augie Fackler |
Line 71: | Line 81: |
* '''Project description''': Current graph rendering code in hgweb is pretty clunky and not very extensible or efficient. We could update it to use hgweb's own JSON API, to be faster and smarter, to show more things and to look nicer. * '''Skills''': Python (server-side), JavaScript (client-side) * '''Difficulty level''': Intermediate/Difficult * '''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''': * '''Potential mentors''': ? |
==== Project description ==== |
Line 78: | Line 83: |
'''A list of possible improvements''' | Current graph rendering code in hgweb is pretty clunky and not very extensible or efficient. We could update it to use hgweb's own JSON API, to be faster and smarter, to show more things and to look nicer. You can view an example of the [[https://selenic.com/repo/hg|current hgweb interface]]. This task can vary a lot depending on your own preferences, as you can do quite a few different subtasks. |
Line 92: | Line 98: |
=== Moving toward Python3 === | ==== Project properties |
Line 94: | Line 100: |
* '''Project description''': Upgrading the code base toward Python until we hit the actually tricky issue Moving Mercurial to Python is not a simple task, but we have a large amount of work that need to be done before we can hit the actual hard problems regarding bytes and unicode. The various step we need to take are described in the [[Python3]] page. * '''Skills''': Python * '''Difficulty level''': Medium (?) * '''Related reading/Links''': [[Python3]] * '''Further details''': See [[Python3]]. * '''Point of Contact''': Greg Szorc, Augie Fackler |
* '''Skills''': Python (server-side), JavaScript (client-side) * '''Difficulty level''': Intermediate (but 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''': av6 on IRC |
GSoC Student Guidance and Project Ideas for 2016
Please see also our SummerOfCode/2016 page, which contains additional information for GSoC for this year.
Contents
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:
Check the SummerOfCode/Ideas2016 page
Subscribe to this page to get email when it changes
Introduce yourself on IRC
Introduce yourself on the mailing list
Read the ContributingChanges pages.
Look at the easy bugs list and contribute a patch. Feel free to ask questions on IRC or the mailing list while getting started!
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 2016 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. Moving toward Python3
5.2.1. Project description
Mercurial currently only supports Python 2. We'd like to improve Python3 support, but that will require a lot of work. A large amount of the work is relatively simple. Some of the first tasks needed will be:
Fixing the warnings in the Python3 compatibility test (test-check-py3-compat.t).
Fix imports to use absolute_import across the code base. Some examples of this work are available.
- Some of our modules don't yet parse in Python3. This needs to be fixed as well.
We currently use 2to3 to compile to Python3 bytecode. Rather than using this, we should unify our codebase to work in Python2 and Python3.
- Some Python modules have different names or different properties in Python3. A compatibility layer (or conditional imports) will be necessary to handle these changes.
Further (also more difficult) tasks are listed on the Python3 page, but the above will most likely take up quite a bit of time already.
==== Project properties
Skills: Python
Difficulty level: Easy
Related reading/Links: Python3
Further details: See Python3.
Point of Contact: Greg Szorc, Augie Fackler
Potential mentors: ?
5.3. Modernize hgweb's graph rendering
5.3.1. Project description
Current graph rendering code in hgweb is pretty clunky and not very extensible or efficient. We could update it to use hgweb's own JSON API, to be faster and smarter, to show more things and to look nicer. You can view an example of the current hgweb interface. This task can vary a lot depending on your own preferences, as you can do quite a few different subtasks.
- Think up a good (extensible, self-descriptive) format for graph data to put into JSON and implement it server-side
- Update client-side code to use JSON for initial rendering and rendering on scroll-down ("infinite scroll")
- Make client-side code to render graph in chunks (will help with performance after a number of infinite-scrolls and will solve issue4020)
Maybe use SVG instead of <canvas>
- Add (non-public) phases to commits in graph (next to branches, tags and bookmarks)
- Display special (e.g. branch-closing) commits in a different way
- Display special edges, such as source-destination of a graft
- Add an ability to see obsoleted changesets (including obsolescence edge)
- Show faded-out edge(s) from the nodes on the top of the screen if they have children (e.g. when tip is not the topmost graph node), this is already done for nodes with parents at the screen bottom
More ideas and visual decisions could be borrowed from TortoiseHg, BitBucket and Kiln.
==== Project properties
Skills: Python (server-side), JavaScript (client-side)
Difficulty level: Intermediate (but 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: av6 on IRC
Potential mentors: ?
5.4. Implement templating for more commands
Project description: Implement templates for all commands that output information.
- hg log famously has a flexible templating language. All commands that output information should leverage this to provide fully customizable output, from bookmarks to blame.
Skills: Python
Difficulty level: Moderate (?)
Related reading/Links:
Further details:
Point of Contact:
Potential mentors:
5.5. Allow largefiles to be at a different location
Project description: Allow largefiles to be at a different location.
- Currently, largefiles must be stored in the same location as the main hosting server. The goal of this project would be to 1) allow the user to change the location (to say, a central file server for a team) and 2) all the server to send a url (with an authentication token) to the client that would tell the client where to push the largefile.
Skills: Python
Difficulty level: Moderate (?)
Related reading/Links:
Further details:
Point of Contact:
Potential mentors: Sean Farley
6. Other ideas?
Come talk to us on IRC.