|
Size: 11123
Comment: Remove asak from the mentor list.
|
Size: 17765
Comment: I intend to tackle subrepositories myself for 1.3
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| Mercurial is a Distributed Version Control System (DVCS), and we are one of the mentoring organizations for 2008's Summer of Code (see also http://code.google.com/soc/2008/hg/about.html). In recent years (notably since the Linux kernel project started looking for a new VCS), DVCSs have rapidly started to gain traction. For Open Source projects, especially, the use of a distributed system can be a great enabler, in that it's much easier to keep track of your own changes and publish them back to the community in a structured way. With centralized systems, you have a central repository that only a happy few have (write) access to, and people spend a lot of time mailing around diffs. With distributed systems, everyone has their own branch, and it's very easy to publish it on the web, compare the changes to those on some other branch or merge two branches back together. | Mercurial is a Distributed Version Control System (DVCS), and we would like to participate in 2009's Summer of Code. In recent years (notably since the Linux kernel project started looking for a new VCS), DVCSs have rapidly started to gain traction. For open source projects, especially, the use of a distributed system can be a great enabler, in that it's much easier to keep track of your own changes and publish them back to the community in a structured way. With centralized systems, you have a central repository that only a happy few have (write) access to, and people spend a lot of time mailing around diffs. With distributed systems, everyone has their own branch, and it's very easy to publish it on the web, compare the changes to those on some other branch or merge two branches back together. |
| Line 8: | Line 8: |
| We believe distributed version control is the future, and it looks like many other technologists believe the same. There's some healthy competition between Open Source VCS systems. In one corner, there's the old CVS and the better, but still centralized and complex Subversion, and in the other corner, there are three main contenders in the distributed VCS space: git, Bazaar-NG and Mercurial. The competition for users is fierce and stimulates fast-paced development in all three systems. It's therefore important (and good for the competition) that projects like ours gain more developers, to keep up with the race for robustness, performance and features. We view the Summer of Code as a great opportunity to help us in this competition. | We believe distributed version control is the future, and it looks like many other technologists believe the same. There's some heavy competition between open source VCS systems: git, Bazaar-NG and Mercurial are constantly fighting over users, while many more conservative projects are still on Subversion or even CVS. Competition is fierce, stimulating fast-paced development in the three DVCS contenders. It's therefore important (and good for the competition) that projects like ours gain more developers, to keep up with the race for robustness, performance and features. We view the Summer of Code as a great opportunity to help us in this competition. |
| Line 14: | Line 14: |
| == Notes on applying == Here are some tips on what you might want to include in your application. * First of all: get feedback on your proposal from the community. The MailingLists and IRC (#mercurial on irc.freenode.net) are quite responsive. Ask around and get to know some people, see if they think your project is feasible or how you should change the scope to better fit the timeline and the project. (If you are new to Open Source development, reading [http://producingoss.com/en/communications.html#you-are-what-you-write this part of "Producing OSS"] may help you find the right tone.) Talking to people before applying dramatically increases your chances of approval: it shows us that you are genuinely able to communicate your ideas, allows us to gauge your expertise level and see who might be the right mentor for you. * Tell us about yourself. We don't know you, so it helps if you give an outline of your background and what your prior experiences are (e.g. Open Source development, using Python, general software engineering experience or education). If it turns out you wouldn't be a good fit for Mercurial or your project idea, it's helpful for everyone involved if that can be determined before you get started. However, don't hesitate to apply just because this would be your first time working in Open Source or with Python; at some point this was new for each of us. * Make it clear that you've thought through your application. Don't use a project idea from this page verbatim. Instead, come up with your own proposal, or expand on a proposal from this page. Explore the code a little bit (it's Python, quite easy to read), read CategoryContributing to get a feel for how the community works. Make a clear schedule to show the intermediate milestones you'll reach while progressing towards your final goal. * Let us know why you care, what you like about DVCSs in general and Mercurial specifically, what things you think could be improved and how they could be improved. We like working on this project because this project makes our work more effective, and we hope you'll like it, too. Showing your motivation helps. == Getting things done == Some tips on how you can get to project completion within the scheduled timeline. * Working on Mercurial in the summer should be your main activity. Having a vacation for one or two weeks is fine, of course, but we want you to take the project and the time mentors put into it seriously. If you are working two other jobs this summer, that probably won't work. Realize that collaborating on software development takes time, and not just the time used to reason about and write the code. This also means that we want you to set some intermediate milestones to be able to keep track of your progress. * Communicate. In some ways, open source software development is more about communicating than about writing code. Some part of your time will be spent writing code, but a large part of the time spent will go towards explaining the code on mailing lists, asking and answering questions on IRC and in general reasoning about proposed software changes. If you can't do this, you take the risk of not understanding the goals of our project or not being able to explain why your patch is necessary. * We want you to work in the open, with our community. Get on the MailingLists, both to ask for help and to provide it to other users, spend time on IRC (#mercurial on irc.freenode.net) discussing your work with other developers and explaining Mercurial to all the new users coming in with questions. Set up a public repository with an MQ containing your patches against the [:CrewRepository:crew repository] (on [http://bitbucket.org/ Bitbucket], for instance; see also MercurialHosting). * We're not going to just compare what you did at the end to what you stated you'd be doing in the beginning. We want you to put effort into the project, to think about the feature you're doing, to communicate with the community and integrate your code with the project. If you end up implementing some other cool feature or fixing some annoyance, that is great as well. |
|
| Line 18: | Line 42: |
| === Instantaneous status on Windows, OS X === | === Lightweight copies/renames === |
| Line 20: | Line 44: |
| The InotifyExtension makes a huge difference to performance on moderate to large [:Repository:repositories] on Linux. Since Windows and Mac OS X provide file status notification APIs, it should be possible to port the inotify extension to one or other (or both) of these platforms, providing the same kinds of speed improvements as on Linux. | (very difficult - a successful student will become an expert in Mercurial's storage format and transmission protocol) Copies and renames currently are not too efficient. Mercurial copies the copied/renamed source file to the new initial revision of the target file in its internal history store. For renames, this is especially counter-intuitive, as renaming a large file grows the store by the file's size. It would be better if Mercurial had some way of referring to the existing revision from the new file, while preserving backwards compatbility and bounded I/O guarantees for retrieving revisions. See [http://www.selenic.com/mercurial/bts/issue883 issue883] for discussion. === Parent Delta === (very difficult - a successful student will become an expert in Mercurial's storage format and transmission protocol) Revlogs such as the manifest that have significant amounts of branching can suffer from revlog's linear delta model. Parent delta would allow storing deltas against parent revisions, greatly improving compression. Like lightweight copies, it will require extending the wire protocol to allow backwards compatibility. === Better Changeset Discovery === (difficult - a successful student will become an expert in Mercurial's protocol and will experiment with difficult graph theory) Mercurial currently uses a simple graph discovery protocol to discover what new changesets need to be pushed or pulled without transmitting the entire list available on either side. We suspect that a significantly better protocol exists that has fewer round trips and less data transfer, but research remains. |
| Line 24: | Line 62: |
| Currently, it's only possible to clone one whole repository at a time. PartialClone and TrimmingHistory could help make cloning more efficient by limiting the cloning process in either of two dimensions: time or space. For time, we could maybe clone the last few [:ChangeSet:changesets] and lazily fetch the rest as needed. For space, it would be nice if it was possible to clone just a subtree of any repositories. For these features, any number of thorny issues can arise because of current assumptions in Mercurial code. | (difficult - a successful student will become familiar with most of Mercurial's core algorithms) |
| Line 26: | Line 64: |
| === Lightweight copies/renames === | (existing work in progress - contact Peter Arrenbrecht, parren on irc) |
| Line 28: | Line 66: |
| Copies and renames currently are not light-weight. Mercurial copies the copied/renamed source file to the new initial revision of the target file in its internal history store. For renames, this is especially counter-intuitive, as renaming a large file grows the store by the file's size. It would be better if Mercurial had some way of referring to the existing revision from the new file, while preserving its bounded I/O guarantees for retrieving revisions. | Currently, it's only possible to clone one whole repository at a time. PartialClone and TrimmingHistory could help make cloning more efficient by limiting the cloning process in either of two dimensions: time or space. For time, we could maybe clone the last few [:ChangeSet:changesets] and lazily fetch the rest as needed. For space, it would be nice if it was possible to clone just a subtree of any repositories. For these features, any number of thorny issues can arise because of current assumptions in Mercurial code. These are hard projects, but the result will be worth it to many Mercurial users (in terms of developers and in terms of projects). |
| Line 30: | Line 68: |
| === Interactive patch selection for commit/Mercurial Queues/record/import === | === Instantaneous status on Linux, Windows, OS X === |
| Line 32: | Line 70: |
| Being able to select parts of the existing changes, with hunk or greater granularity, in an interactive way can improve a lot the use of commands and extensions that take changes, as commit, mercurial queues, record or import. Record currently allows patch hunk selection, but sometimes a better granularity is desired, as when a set of adjacent function definitions should go in different commits. This feature could be added as an {{{--interactive mode}}} for some commands. | (difficult - a successful student will need to debug complex race conditions and master Mercurial's dirstate algorithms) |
| Line 34: | Line 72: |
| === Subrepositories === The ForestExtension implements a solution for repositories that want to include a number of subrepositories (similar to svn:externals). For large projects and because DVCS systems in general advocate smaller repositories, it can be helpful to implement a coherent set of repositories. A [NestedRepositories subrepositories implementation] is in the works but it needs further polish, and integration into the mercurial core, as well as extended functionality, as the capability to use other VCS sources. |
The InotifyExtension makes a huge difference to performance on moderate to large [:Repository:repositories] on Linux, but it still has some difficult bugs. Windows and Mac OS X provide file status notification APIs, so it should be possible to port the inotify extension to one or other (or both) of these platforms, providing the same kinds of speed improvements as on Linux. (Don't try to do all of these in one project; instead, pick one platform you are comfortable with, read about the relevant APIs, then come up with a coherent proposal.) |
| Line 42: | Line 78: |
| === Interactive patch selection for commit/Mercurial Queues/record/import === Being able to select parts of the existing changes, with hunk or greater granularity, in an interactive way, can improve the use of commands and extensions that take changes, such as commit, MercurialQueues and import. The RecordExtension currently allows patch hunk selection, but sometimes a better granularity is desired, as when a set of adjacent function definitions should go in different commits. This feature could be added as an {{{--interactive}}} mode for many of Mercurial's core commands. === Mercurial on Jython === Some Sun projects have taken to using Mercurial as their VCS of choice (OpenJDK, NetBeans; see ProjectsUsingMercurial for a full list). Recently, Mercurial has re-gained pure-Python implementations of the modules that are now in C. It would be nice if someone could take the effort to get this code to run on Jython, opening up Mercurial for use from within the JDK. === Mercurial on Py3k === (difficult - a successful student will have to master Mercurial's pervasive approach to character set handling and reconcile it with Py3k's) In 2008, the Python project has finally released their 3.0 branch of Python (affectionately known as Python 3000). This is a major release of Python, with some large changes. Porting to Py3k would be an interesting effort, operating on the current edge of the software, with nice long-term viability results for Mercurial. |
|
| Line 44: | Line 94: |
| Mercurial is currently lacking features to support integration into a GUI, like TortoiseHg or Mercurial Eclipse. One example of a feature that would benefit GUI is [http://www.nabble.com/Progress-bar-on-network-actions-tt20596124.html#a20596124 a progress indicator] on operations that may take some time | Mercurial is currently lacking features to support integration into a GUI, like TortoiseHg or Mercurial Eclipse. One example of a feature that would benefit GUI is [http://www.nabble.com/Progress-bar-on-network-actions-tt20596124.html#a20596124 a progress indicator] on operations that may take some time. === Web interface work === The hgwebdir repository interface is one of the successful parts of Mercurial. It allows projects to quickly setup a web interface with access to multiple repositories, and it has some decent ACL features. It's a Python WSGI application, meaning it's relatively easy to run on many platforms and behind differing web servers. It can still be improved, though: there are still some holes in the WSGI implementation (notably, it writes to stdout/stderr in some error conditions) and the access control features aren't always functional enough for complex setups. Also, improved support for named branches and filtering (like hg log -f and the like) are often requested features. |
| Line 50: | Line 106: |
| The hgsubversion extension already works quite well, but better integration with the existing mercurial user interface would be nice. | The hgsubversion extension already works quite well, but better integration with the existing Mercurial user interface would be nice. |
| Line 52: | Line 108: |
| === C version of some lower-level operations === | === Performance tuning === |
| Line 54: | Line 110: |
| It should be possible to extract a large performace improvement from writing a C version of some basic operations. The main candidate for this would be the code that handles the index of a [:RevlogNG:revlog]; other parts of the revlog implementation (like the heads operation that is used in the WireProtocol and when calculating tags) could also benefit quite a bit. | (difficult - a successful student will master performance benchmarking, tuning Python algorithms, and possibly writing C extensions in Python) |
| Line 56: | Line 112: |
| Some work has already been done at http://sharesource.org/project/hgc/ | There are numerous opportunities for additional performance tuning. Possibilities include: |
| Line 58: | Line 114: |
| == Notes on applying == | * faster startup (can we optimize Python load time further? can we minimize loading of unused code further?) * faster status (can we further improve directory walking? ignore logic? dirstate parsing?) * faster checkout (can we reduce the overhead of our file I/O paths?) |
| Line 60: | Line 118: |
| Here are some tips on what you might want to include in your application. | A project in this area would probably involve picking an important benchmark (eg checkout of a large repository) and tuning multiple areas to meet a performance goal (eg 2x overall performance increase). |
| Line 62: | Line 120: |
| * Tell us something about yourself. We don't know you, so it helps if you give an outline of your background and what your prior experiences are (e.g. Open Source development, using Python, general software engineering experience or education). But don't hesitate to apply just because this would be your first time working in Open Source or with Python; at some point this was new for each of us. | === MercurialEclipse === |
| Line 64: | Line 122: |
| * Make it clear that you've thought through your application. Don't use a project idea from this page verbatim. Instead, come up with your own proposal, or expand on a proposal from this page. Explore the code a little bit (it's Python, quite easy to read), read CategoryContributing to get a feel for how the community works. Make something of a schedule with some intermediate milestones that progress toward your project's goal. | ==== Mylin Integration ==== |
| Line 66: | Line 124: |
| * Communicate why you care, what you like about DVCSs in general and Mercurial specifically, what things you think could be improved and how they could be improved. We like working on this project because this project makes our work more effective, and we hope you'll like it, too. Showing your motivation helps. | Integrate the Mercurial changeset backend in MercurialEclipse with the Eclipse Mylin facilities. |
| Line 68: | Line 126: |
| * Get feedback on your proposal from the community. The MailingLists and IRC (#mercurial on irc.freenode.net) are quite responsive. Ask around and get to know some people, see if they think your project is feasible or how you should change the scope to better fit the timeline and the project. (If you are new to Open Source development, reading [http://producingoss.com/en/communications.html#you-are-what-you-write this part of "Producing OSS"] may help you find the right tone.) | ==== Improve synchronize view ==== |
| Line 70: | Line 128: |
| == Getting things done == | Use structural compare in synchronize view. Visualize remote / local changes by applying them to a DAG. This could use some work already done by Brian Wallis. |
| Line 72: | Line 130: |
| Some idea of how we would expect the project to be carried out. | ==== Fully support pbranch and attic extensions ==== |
| Line 74: | Line 132: |
| * Working on Mercurial in the summer should be your main activity. Having a vacation for one or two weeks is fine, of course, but we want you to take the project and the time mentors put into it seriously. This also means that we want you to set some intermediate milestones to be able to keep track of your progress. | Support all commands, including interactive interfacing with Mercurial. |
| Line 76: | Line 134: |
| * We want you to work in the open, with our community. Get on the MailingLists, both to ask for help and to provide it to other users, spend some time on IRC (#mercurial on irc.freenode.net) discussing your work with other developers and explaining Mercurial to all the new users coming in with questions. Set up a public repository with an MQ containing your patches against the [:CrewRepository:crew repository] (on [http://freehg.org/ freehg.org], for instance; see also MercurialHosting). | ==== Bitbucket.org, FreeHG (or other hosting services) integration ==== |
| Line 78: | Line 136: |
| * We're not going to just compare what you did at the end to what you stated you'd be doing in the beginning. We want you to put effort into the project, to think about the feature you're doing, to communicate with the community and integrate your code with the project. If you end up implementing some other cool feature or fixing some annoyance, that is great as well. | Create a new repository (and maybe even a account) transparently from Eclipse. Interface with the bitbucket.org API. Jesper Noehr would be willing to help with this. Even interfacing with SVN repository providers might be an option by using hgsubversion. ==== Native Java implementation of mercurial ==== This might be too big, but would enable Java programs to talk directly to Mercurial. ==== Improve Patch workflow ==== Working with patches could be improved and streamlined by e.g. supporting copy & paste within package explorer / navigator, triggering the patchbomb extension from within mq/shelve support etc. Importing patches from bugzilla/trac/lighthouse/bitbucket/whatever into Mercurial would be nice as well. Mylin could perhaps help with this. ==== Support some "send change for review" workflow ==== Most places where I worked you need to have you your changes review'ed by a colleague before pushing it. and there is usually no "integrator" review'ing and pulling the changeset into the "main" branch that is handled by the developer after his changest got approved. ==== Support release management ==== Make release menu item that Change some file according to a template (version number in the manifest) commit, autogenerate a tag, commit tag, if its a eclipse plugin, generate a feature with the same version number and generate a release. Auto update version on Eclipse Plugin Central ... (it's not hard today just many smal steps maybe not worth it probably totaly different for different project What kind if steps do you need in your project) ==== Integration of Eclipse Mylin with bitbucket.org ticketing ==== Integrate the ticket tool from bitbucket.org with Eclipse's Task/Ticket UI. |
| Line 82: | Line 160: |
| A potential mentor list. | A list of potential mentors. |
| Line 88: | Line 166: |
| * BastianDoetsch (_bastiand_ on IRC) (MercurialEclipse) * Zingo (MercurialEclipse) * IsmaelJuma (MercurialEclipse) * JesperNoehr (Bitbucket/MercurialEclipse integration) |
Google Summer of Code 2009
For the last few years, Google has offered a fantastic opportunity for students to help out Open Source software projects in the summer while getting paid for it. It's called Google Summer of Code™, and it provides free software projects a great way of attracting development effort while providing software developers who are still in university with some interesting and useful experiences. Find out more about the Summer of Code (SoC) from [http://code.google.com/summerofcode.html their site].
Mercurial is a Distributed Version Control System (DVCS), and we would like to participate in 2009's Summer of Code. In recent years (notably since the Linux kernel project started looking for a new VCS), DVCSs have rapidly started to gain traction. For open source projects, especially, the use of a distributed system can be a great enabler, in that it's much easier to keep track of your own changes and publish them back to the community in a structured way. With centralized systems, you have a central repository that only a happy few have (write) access to, and people spend a lot of time mailing around diffs. With distributed systems, everyone has their own branch, and it's very easy to publish it on the web, compare the changes to those on some other branch or merge two branches back together.
We believe distributed version control is the future, and it looks like many other technologists believe the same. There's some heavy competition between open source VCS systems: git, Bazaar-NG and Mercurial are constantly fighting over users, while many more conservative projects are still on Subversion or even CVS. Competition is fierce, stimulating fast-paced development in the three DVCS contenders. It's therefore important (and good for the competition) that projects like ours gain more developers, to keep up with the race for robustness, performance and features. We view the Summer of Code as a great opportunity to help us in this competition.
Written largely in Python (with the exceptions of a few performance-critical core modules), it is easy to develop for and allows for good code organization and clean abstractions. Moreover, it has been optimized from the start for good performance, using an append-only datastore, minimizing random disk access and smart uses of compression. Finally, it has extensive features for sharing changesets, over HTTP, SSH and in files over email and has an innovative extension (Mercurial Queues) to help building and organizing changesets into a thoroughly useful source history.
1. Notes on applying
Here are some tips on what you might want to include in your application.
First of all: get feedback on your proposal from the community. The MailingLists and IRC (#mercurial on irc.freenode.net) are quite responsive. Ask around and get to know some people, see if they think your project is feasible or how you should change the scope to better fit the timeline and the project. (If you are new to Open Source development, reading [http://producingoss.com/en/communications.html#you-are-what-you-write this part of "Producing OSS"] may help you find the right tone.) Talking to people before applying dramatically increases your chances of approval: it shows us that you are genuinely able to communicate your ideas, allows us to gauge your expertise level and see who might be the right mentor for you.
- Tell us about yourself. We don't know you, so it helps if you give an outline of your background and what your prior experiences are (e.g. Open Source development, using Python, general software engineering experience or education). If it turns out you wouldn't be a good fit for Mercurial or your project idea, it's helpful for everyone involved if that can be determined before you get started. However, don't hesitate to apply just because this would be your first time working in Open Source or with Python; at some point this was new for each of us.
Make it clear that you've thought through your application. Don't use a project idea from this page verbatim. Instead, come up with your own proposal, or expand on a proposal from this page. Explore the code a little bit (it's Python, quite easy to read), read CategoryContributing to get a feel for how the community works. Make a clear schedule to show the intermediate milestones you'll reach while progressing towards your final goal.
- Let us know why you care, what you like about DVCSs in general and Mercurial specifically, what things you think could be improved and how they could be improved. We like working on this project because this project makes our work more effective, and we hope you'll like it, too. Showing your motivation helps.
2. Getting things done
Some tips on how you can get to project completion within the scheduled timeline.
- Working on Mercurial in the summer should be your main activity. Having a vacation for one or two weeks is fine, of course, but we want you to take the project and the time mentors put into it seriously. If you are working two other jobs this summer, that probably won't work. Realize that collaborating on software development takes time, and not just the time used to reason about and write the code. This also means that we want you to set some intermediate milestones to be able to keep track of your progress.
- Communicate. In some ways, open source software development is more about communicating than about writing code. Some part of your time will be spent writing code, but a large part of the time spent will go towards explaining the code on mailing lists, asking and answering questions on IRC and in general reasoning about proposed software changes. If you can't do this, you take the risk of not understanding the goals of our project or not being able to explain why your patch is necessary.
We want you to work in the open, with our community. Get on the MailingLists, both to ask for help and to provide it to other users, spend time on IRC (#mercurial on irc.freenode.net) discussing your work with other developers and explaining Mercurial to all the new users coming in with questions. Set up a public repository with an MQ containing your patches against the [:CrewRepository:crew repository] (on [http://bitbucket.org/ Bitbucket], for instance; see also MercurialHosting).
- We're not going to just compare what you did at the end to what you stated you'd be doing in the beginning. We want you to put effort into the project, to think about the feature you're doing, to communicate with the community and integrate your code with the project. If you end up implementing some other cool feature or fixing some annoyance, that is great as well.
3. Project Ideas
Here are a bunch of project ideas you might like to apply for. Of course, if you have a different idea of something in Mercurial that badly needs fixing or some feature you think would make a difference, go ahead and apply with it! Some more project ideas can be found via NewFeatureDiscussions, CategoryNewFeatures and NewIdeas.
3.1. Lightweight copies/renames
(very difficult - a successful student will become an expert in Mercurial's storage format and transmission protocol)
Copies and renames currently are not too efficient. Mercurial copies the copied/renamed source file to the new initial revision of the target file in its internal history store. For renames, this is especially counter-intuitive, as renaming a large file grows the store by the file's size. It would be better if Mercurial had some way of referring to the existing revision from the new file, while preserving backwards compatbility and bounded I/O guarantees for retrieving revisions. See [http://www.selenic.com/mercurial/bts/issue883 issue883] for discussion.
3.2. Parent Delta
(very difficult - a successful student will become an expert in Mercurial's storage format and transmission protocol)
Revlogs such as the manifest that have significant amounts of branching can suffer from revlog's linear delta model. Parent delta would allow storing deltas against parent revisions, greatly improving compression. Like lightweight copies, it will require extending the wire protocol to allow backwards compatibility.
3.3. Better Changeset Discovery
(difficult - a successful student will become an expert in Mercurial's protocol and will experiment with difficult graph theory)
Mercurial currently uses a simple graph discovery protocol to discover what new changesets need to be pushed or pulled without transmitting the entire list available on either side. We suspect that a significantly better protocol exists that has fewer round trips and less data transfer, but research remains.
3.4. Partial cloning
(difficult - a successful student will become familiar with most of Mercurial's core algorithms)
(existing work in progress - contact Peter Arrenbrecht, parren on irc)
Currently, it's only possible to clone one whole repository at a time. PartialClone and TrimmingHistory could help make cloning more efficient by limiting the cloning process in either of two dimensions: time or space. For time, we could maybe clone the last few [:ChangeSet:changesets] and lazily fetch the rest as needed. For space, it would be nice if it was possible to clone just a subtree of any repositories. For these features, any number of thorny issues can arise because of current assumptions in Mercurial code. These are hard projects, but the result will be worth it to many Mercurial users (in terms of developers and in terms of projects).
3.5. Instantaneous status on Linux, Windows, OS X
(difficult - a successful student will need to debug complex race conditions and master Mercurial's dirstate algorithms)
The InotifyExtension makes a huge difference to performance on moderate to large [:Repository:repositories] on Linux, but it still has some difficult bugs. Windows and Mac OS X provide file status notification APIs, so it should be possible to port the inotify extension to one or other (or both) of these platforms, providing the same kinds of speed improvements as on Linux. (Don't try to do all of these in one project; instead, pick one platform you are comfortable with, read about the relevant APIs, then come up with a coherent proposal.)
3.6. TortoiseHg
TortoiseHg is a GUI front-end, similar to TortoiseCVS and TortoiseSVN. For many people, this makes interacting with Mercurial much easier. There's a lot of room for improvement, adding graphical UI to interesting extensions like pbranch and others. The project keeps a [http://bitbucket.org/tortoisehg/crew/wiki/TODO TODO list] of suitable tasks for a Summer of Code.
3.7. Interactive patch selection for commit/Mercurial Queues/record/import
Being able to select parts of the existing changes, with hunk or greater granularity, in an interactive way, can improve the use of commands and extensions that take changes, such as commit, MercurialQueues and import. The RecordExtension currently allows patch hunk selection, but sometimes a better granularity is desired, as when a set of adjacent function definitions should go in different commits. This feature could be added as an --interactive mode for many of Mercurial's core commands.
3.8. Mercurial on Jython
Some Sun projects have taken to using Mercurial as their VCS of choice (OpenJDK, NetBeans; see ProjectsUsingMercurial for a full list). Recently, Mercurial has re-gained pure-Python implementations of the modules that are now in C. It would be nice if someone could take the effort to get this code to run on Jython, opening up Mercurial for use from within the JDK.
3.9. Mercurial on Py3k
(difficult - a successful student will have to master Mercurial's pervasive approach to character set handling and reconcile it with Py3k's)
In 2008, the Python project has finally released their 3.0 branch of Python (affectionately known as Python 3000). This is a major release of Python, with some large changes. Porting to Py3k would be an interesting effort, operating on the current edge of the software, with nice long-term viability results for Mercurial.
3.10. GUI integration
Mercurial is currently lacking features to support integration into a GUI, like TortoiseHg or Mercurial Eclipse. One example of a feature that would benefit GUI is [http://www.nabble.com/Progress-bar-on-network-actions-tt20596124.html#a20596124 a progress indicator] on operations that may take some time.
3.11. Web interface work
The hgwebdir repository interface is one of the successful parts of Mercurial. It allows projects to quickly setup a web interface with access to multiple repositories, and it has some decent ACL features. It's a Python WSGI application, meaning it's relatively easy to run on many platforms and behind differing web servers. It can still be improved, though: there are still some holes in the WSGI implementation (notably, it writes to stdout/stderr in some error conditions) and the access control features aren't always functional enough for complex setups.
Also, improved support for named branches and filtering (like hg log -f and the like) are often requested features.
3.12. Conversion tools
Mercurial is a relatively new entrant in the VCS market, and many projects are still using older VCSs such as CVS and SVN. While we currently have some tools to help migrate to Mercurial in the form of the ConvertExtension, these tools could certainly use more improvements. Specifically, enabling the use of Mercurial as a client for SVN or even git and/or Bazaar-NG repositories would be very nice, as it enables developers to make their own choice regarding the use of their VCS client, thereby drastically enlarging our userbase.
The hgsubversion extension already works quite well, but better integration with the existing Mercurial user interface would be nice.
3.13. Performance tuning
(difficult - a successful student will master performance benchmarking, tuning Python algorithms, and possibly writing C extensions in Python)
There are numerous opportunities for additional performance tuning. Possibilities include:
- faster startup (can we optimize Python load time further? can we minimize loading of unused code further?)
- faster status (can we further improve directory walking? ignore logic? dirstate parsing?)
- faster checkout (can we reduce the overhead of our file I/O paths?)
A project in this area would probably involve picking an important benchmark (eg checkout of a large repository) and tuning multiple areas to meet a performance goal (eg 2x overall performance increase).
3.14. MercurialEclipse
3.14.1. Mylin Integration
Integrate the Mercurial changeset backend in MercurialEclipse with the Eclipse Mylin facilities.
3.14.2. Improve synchronize view
Use structural compare in synchronize view. Visualize remote / local changes by applying them to a DAG. This could use some work already done by Brian Wallis.
3.14.3. Fully support pbranch and attic extensions
Support all commands, including interactive interfacing with Mercurial.
3.14.4. Bitbucket.org, FreeHG (or other hosting services) integration
Create a new repository (and maybe even a account) transparently from Eclipse. Interface with the bitbucket.org API. Jesper Noehr would be willing to help with this. Even interfacing with SVN repository providers might be an option by using hgsubversion.
3.14.5. Native Java implementation of mercurial
This might be too big, but would enable Java programs to talk directly to Mercurial.
3.14.6. Improve Patch workflow
Working with patches could be improved and streamlined by e.g. supporting copy & paste within package explorer / navigator, triggering the patchbomb extension from within mq/shelve support etc. Importing patches from bugzilla/trac/lighthouse/bitbucket/whatever into Mercurial would be nice as well. Mylin could perhaps help with this.
3.14.7. Support some "send change for review" workflow
Most places where I worked you need to have you your changes review'ed by a colleague before pushing it. and there is usually no "integrator" review'ing and pulling the changeset into the "main" branch that is handled by the developer after his changest got approved.
3.14.8. Support release management
Make release menu item that Change some file according to a template (version number in the manifest) commit, autogenerate a tag, commit tag, if its a eclipse plugin, generate a feature with the same version number and generate a release. Auto update version on Eclipse Plugin Central ... (it's not hard today just many smal steps maybe not worth it probably totaly different for different project What kind if steps do you need in your project)
3.14.9. Integration of Eclipse Mylin with bitbucket.org ticketing
Integrate the ticket tool from bitbucket.org with Eclipse's Task/Ticket UI.
4. Mentors
A list of potential mentors.
[wiki:mpm MattMackall] (mpm on IRC; creator of Mercurial)
DirkjanOchtman (djc on IRC)
PeterArrenbrecht (parren on IRC)
AugieFackler (durin42 on IRC)
BastianDoetsch (_bastiand_ on IRC) (MercurialEclipse)
Zingo (MercurialEclipse)
JesperNoehr (Bitbucket/MercurialEclipse integration)
5. Students Considering Application
6. Applications Received From
7. Project status
8. Other GSoc Projects related to Mercurial
"Google Summer of Code" is a trademark by Google Inc.