|
Size: 315
Comment: First version of new SoC page, linking to related pages.
|
Size: 3005
Comment: Include a list of project ideas.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| Mercurial is applying as a mentoring organization for the Summer of Code 2008. Here are some project ideas and other information for students. | Mercurial is applying as a mentoring organization for the Summer of Code 2008. |
| Line 7: | Line 7: |
| For more project ideas, peruse the pages linked to by NewFeaturesDiscussion, CategoryNewFeatures and NewIdeas. | 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. === Improved named branches === While Mercurial already somewhat supports having multiple actual branches in one repository, this support is perhaps less than polished. It would be nice, for example, if the web interface had better ways to expose the branches and if it became possible to explicitly close old branches. The named branch support really could use a lot of spit & polish. === Partial cloning === 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 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. === Lightweight copies/renames === Copies and renames currently copy all of the history from the old file to the new file, doubling the space used by that history in the process. It would be better if the code had some way of referring to the old history from the new file, so that the same on-disk file history is shared by the copies up to the point of copying. === Mercurial Queues improvements === Mercurial Queues (MqExtension) is a somewhat unique feature of Mercurial allowing a very flexible way of accumulating history before finally writing it to the actual changelog. Currently, it has a number of rough edges that sometimes cause problems when Mercurial is suddenly interrupted or when the user acts in unforeseen ways. Additionally, rebasing with MQ, while generally pretty easy, is a more elaborate process than it needs to be. It would be nice if MQ grew a little smarter about some of the common cases and a little more robust in the face of inexperienced users. === Repository forests === 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. The extension currently tries to do this, but it has proved to be less than intuitive and possibly not the best design. It would be good if Mercurial could incorporate an improved version of this extension. == Mentors == * PeterArrenbrecht * DirkjanOchtman ---- CategoryNewFeatures |
Google Summer of Code 2008
Mercurial is applying as a mentoring organization for the Summer of Code 2008.
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.
Improved named branches
While Mercurial already somewhat supports having multiple actual branches in one repository, this support is perhaps less than polished. It would be nice, for example, if the web interface had better ways to expose the branches and if it became possible to explicitly close old branches. The named branch support really could use a lot of spit & polish.
Partial cloning
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 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.
Lightweight copies/renames
Copies and renames currently copy all of the history from the old file to the new file, doubling the space used by that history in the process. It would be better if the code had some way of referring to the old history from the new file, so that the same on-disk file history is shared by the copies up to the point of copying.
Mercurial Queues improvements
Mercurial Queues (MqExtension) is a somewhat unique feature of Mercurial allowing a very flexible way of accumulating history before finally writing it to the actual changelog. Currently, it has a number of rough edges that sometimes cause problems when Mercurial is suddenly interrupted or when the user acts in unforeseen ways. Additionally, rebasing with MQ, while generally pretty easy, is a more elaborate process than it needs to be. It would be nice if MQ grew a little smarter about some of the common cases and a little more robust in the face of inexperienced users.
Repository forests
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. The extension currently tries to do this, but it has proved to be less than intuitive and possibly not the best design. It would be good if Mercurial could incorporate an improved version of this extension.