# # # rename "wiki/SummerOfCode/2007.moin" # to "wiki/SummerOfCode/2007.mdwn" # # patch "wiki/SummerOfCode/2006.mdwn" # from [a7d294e9ec6d3aebbe25421ca6b61a1e7fdc1c22] # to [880ea2f71552bdbb56f0f7288f49f0cd9d242e90] # # patch "wiki/SummerOfCode/2007/Ideas.mdwn" # from [420b0d4122e6423d940b7a1dc5057e4123db03bc] # to [fd45fa644b08666ece174cf5b9e3464593d12003] # # patch "wiki/SummerOfCode/2007.mdwn" # from [62c644fe7fffe2aa2f5c00c51bd509474d8b128b] # to [75f61f221e76a51588bcbe0531a3d9e4ba8e2fa5] # ============================================================ --- wiki/SummerOfCode/2006.mdwn a7d294e9ec6d3aebbe25421ca6b61a1e7fdc1c22 +++ wiki/SummerOfCode/2006.mdwn 880ea2f71552bdbb56f0f7288f49f0cd9d242e90 @@ -1,4 +1,5 @@ -[[!tag migration-auto]] +[[!tag migration-done]] +[[!toc levels=2]] # Google Summer of Code -- 2006 @@ -6,7 +7,7 @@ information is available on [their site] with FLOSS development this summer, and get paid for doing it. More information is available on [their site](http://code.google.com/summerofcode.html). -[Monotone](http://venge.net/monotone) is a version control +[Monotone](http://monotone.ca) is a version control system, and we're one of the mentoring organizations for SoC 2006. The rest of this page contains information for students considering applying to the monotone project. @@ -18,7 +19,7 @@ systems, and robustly solving complex re else's'' work more effective. We're pushing the boundaries of technology, inventing new methods for building distributed p2p systems, and robustly solving complex real world problems. Our -[history representation](http://venge.net/monotone/docs/Historical-records.html) +[[history_representation|docs/Historical-records.html]] has become the de facto standard for [new](http://git.or.cz/) [tools](http://www.selenic.com/mercurial/); the best existing [merge algorithm](http://revctrl.org/MarkMerge) was co-invented by a Monotone SoC 2005 student. We have a few more @@ -26,18 +27,21 @@ For more information on monotone in gene too -- maybe this is a project for you :-) For more information on monotone in general, the comprehensive -[manual](http://venge.net/monotone/docs) has details on how -monotone works, and the wiki (FrontPage) is used for scratch work +[[manual|docs]] has details on how +monotone works, and the wiki ([FrontPage]) is used for scratch work about various work in progress. Monotone is written in clean and straightforward C++. A number of the projects below do *not* require C++ knowledge. + ## Ideas Here are some example ideas for projects. Feel free to suggest others. + ### Largish projects + * [[MergeViaWorkingDir]]: This has been a number-1 requested feature for ages and ages. Since the release of v0.26 this month, it is now reasonably straightforward to implement! This will involve getting nice and dirty with monotone internals, the details of how @@ -47,7 +51,7 @@ Here are some example ideas for projects [[NonMergeConflicts]]. * Create a performance test harness, and benchmarks using it. This would be _extremely_ valuable for tuning monotone's speed, testing changes, and catching performance regressions. - There are more details [here](http://venge.net/monotone/wiki/PerformanceWork#head-150324c5862f1b409230043ade62a5041c227400). + There are more details [[here|PerformanceWork#automated-performance-testsuite]]. * UI work: find some friends, set them loose on monotone. Watch them carefully and take notes. Write up where-ever they get confused or make mistakes; come up with ways to stop them getting confused. Implement these ways. @@ -62,16 +66,19 @@ Here are some example ideas for projects appropriate things with each (e.g., send the notes to the mailing list and commit any additional changes to the branch directly). + ### Smaller projects + "Buy two, they're cheap" + * [[MagicSelectors]]: enhancing the monotone command line * Add symlink support to monotone * Teach monotone to use ssh-agent to store keys - * Add a way to specify "templates" for [mtn automate](http://venge.net/monotone/docs/Scripting.html) + * Add a way to specify "templates" for [[mtn_automate|docs/Scripting.html]] output; useful for scripting! * "undo" for workspace operations. (Well... not sure if this is small or not.) * clarification wanted: what is undo supposed to do? - * Answer: Use case: I run 'mtn up', and then realize that I screwed up the merge. I want to get back to where I was before. Use case: I meant to run "revert " but instead I accidentally reverted my whole workspace, including valuable uncommitted changes. I want to get back to where I was before. + * Answer: Use case: I run `mtn up`, and then realize that I screwed up the merge. I want to get back to where I was before. Use case: I meant to run "revert " but instead I accidentally reverted my whole workspace, including valuable uncommitted changes. I want to get back to where I was before. * monotone-dumb is a hack to let people host monotone repositories on cheap hosts that only provide static http/ftp access. It works, but could use a bunch of polish to be really usable. [This mailing list post](http://article.gmane.org/gmane.comp.version-control.monotone.devel/6295) @@ -79,15 +86,18 @@ Here are some example ideas for projects * Add the ability to spawn a process and speak netsync to it (a kind of generalized proxy support). Use this to teach monotone to run netsync over jabber/jingle, etc. * clarification wanted: what about this? there's a branch that wants to provide an stdin/stdout interface to monotone. is reviving that and finishing it part of this, or something else? - * Answer: Yes, this is a generalization of the .ssh branch. Basically, the idea would be to make it possible to say "mtn sync --connect-via 'ssh foo.com mtn serve-stdio'", where the argument to --connect-via is an arbitrary command. This would allow people to add interesting new transports. (The UI given here probably isn't optimal, that's just to give the idea.) + * Answer: Yes, this is a generalization of the .ssh branch. Basically, the idea would be to make it possible to say `mtn sync --connect-via 'ssh foo.com mtn serve-stdio'`, where the argument to --connect-via is an arbitrary command. This would allow people to add interesting new transports. (The UI given here probably isn't optimal, that's just to give the idea.) * Our test coverage has been hovering at about 90% for a long time: [current status](http://frances.vorpus.org/~monotone-cov/net.venge.monotone/). Get it higher than that! * Support for "nested trees" -- Some way to combine several projects that are versioned separately into a single workspace, similar to CVS modules, or Arch "configs". There are a fair number of people interested in this, but no design yet; part of the project would be figuring out what exactly everyone wants from this capability. + ### Integration + A VCS is only one piece of the development ecology -- at least as important as the VCS itself is how it fits into the other tools people use. Examples: + * [Trac](http://edgewall.com/trac) is a very popular wiki/bug tracker/source code browser, and it supports plugins for different VCSes. We need a monotone plug-in! Probably the thing to @@ -102,7 +112,9 @@ people use. Examples: * How about file manager integration? [TortoiseSVN](http://tortoisesvn.tigris.org) for Windows Explorer is good inspiration again; could do similar for OS X Finder, Gnome Nautilus, KDE Konqueror, ... + ### Ambitious + These are probably too big for someone who doesn't have familiarity with monotone already to do in a summer, but throwing them out there anyway: @@ -114,8 +126,11 @@ anyway: monotone developers. * Functionality similar to [Quilt](http://savannah.nongnu.org/projects/quilt)/[StGit](http://www.procode.org/stgit/)/[Mq](http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension). See [also](http://article.gmane.org/gmane.comp.version-control.monotone.devel/6577) for why this is tricky... but maybe if someone implemented it, we would discover it was not so tricky after all. + ### Oddballs + A few funky things, that are not *strictly* related to monotone at all: + * "Chryn": Monotone could use a better library for event-handling (network stuff, signals, etc.); several of the things on the list above would be greatly helped by this. Chryn is a half-working @@ -124,6 +139,7 @@ A few funky things, that are not *strict project management system, similar to Trac but with extra coolness. Talk to him if curious about details... + ## Notes on applying So you're thinking of applying? Great! Here are some more general @@ -154,12 +170,15 @@ how we like to do things: Different orgs will be looking for different things, but here are some other good hints on writing a good SoC app that seem compatible with how we like to do things: - * http://drupal.org/node/59037 - * http://www.internet2.edu/~shalunov/tmp/rwatson-soc.txt + * + * + + ## If selected... To give you some idea of how we like to run things, and what to expect: + * Working on monotone should be your main activity through the whole summer. Going out of town for a week on vacation or whatever is fine, but this is a serious commitment and you're working for serious rewards; ============================================================ --- wiki/SummerOfCode/2007/Ideas.mdwn 420b0d4122e6423d940b7a1dc5057e4123db03bc +++ wiki/SummerOfCode/2007/Ideas.mdwn fd45fa644b08666ece174cf5b9e3464593d12003 @@ -1,8 +1,8 @@ -[[!tag migration-auto]] +[[!tag migration-done]] # Ideas for the Google Summer Of Code 2007 -Main page: [[SummerOfCode2007]] +Main page: [[SummerOfCode/2007]] ## monotone @@ -36,7 +36,7 @@ monoclipse (much more sketchy b/c someon ## guitone -Main page: http://guitone.thomaskeller.biz +Main page: * a dag graph view using [libqanava](http://www.libqanava.org/), [libtulip](http://www.tulip-software.org/), [graphviz](http://www.graphviz.org/) or else * a kpart module for the KDE Konqueror based on the existing framework ============================================================ --- wiki/SummerOfCode/2007.moin 62c644fe7fffe2aa2f5c00c51bd509474d8b128b +++ wiki/SummerOfCode/2007.mdwn 75f61f221e76a51588bcbe0531a3d9e4ba8e2fa5 @@ -1,93 +1,95 @@ -[http://code.google.com/soc Summer of Code] is Google's program to help students get involved in free software development; they provide a formal structure, and funding, for students to spend the summer helping real software projects. +[[tag migration-done]] +[[!toc levels=2]] -Here at [http://monotone.ca Monotone], we are ''(hopefully!)'' a mentor organization for Summer of Code 2007. The purpose of this page is to answer any questions you might have about applying to join our project under the Summer of Code program. But, if you still have any questions after reading it, feel free to drop us a line at address@hidden +[Summer of Code](http://code.google.com/soc) is Google's program to help students get involved in free software development; they provide a formal structure, and funding, for students to spend the summer helping real software projects. -= Who are we/what is Monotone? (overview) = +Here at [Monotone](http://monotone.ca/), we are *(hopefully!)* a mentor organization for Summer of Code 2007. The purpose of this page is to answer any questions you might have about applying to join our project under the Summer of Code program. But, if you still have any questions after reading it, feel free to drop us a line at address@hidden +# Who are we/what is Monotone? (overview) + Monotone is a version control system (VCS) -- i.e., the basic program that other projects use to distribute their code, coordinate their work, and generally rely on to get everything done. Because people rely on us to hold all of their work, we have to be extremely reliable. Because people can't get work done at all without their VCS, we need to be portable, keep working in strange situations (e.g., even when people are offline), and easy to use -- so we end up with all sorts of interesting distributed system and user interface problems. And if we do a good enough job, we can guide people to whole new styles of working, so that ''everyone's'' hacking becomes easier, more efficient, and less stressful. -The code itself is written in C++, with a somewhat idiosyncratic style that makes C++ much more pleasant to use than it might otherwise be. Configuration and testing are done using [http://lua.org Lua]. A comprehensive test suite also makes it easy to make complex changes, without worrying that one has accidentally broken critical functionality. Generally speaking, there are tasks to be done involving user interface design, networking code, database storage, novel algorithms... if you like systems programming and are looking for a project that's not "just another web app", then maybe monotone is for you. +The code itself is written in C++, with a somewhat idiosyncratic style that makes C++ much more pleasant to use than it might otherwise be. Configuration and testing are done using [Lua](http://lua.org). A comprehensive test suite also makes it easy to make complex changes, without worrying that one has accidentally broken critical functionality. Generally speaking, there are tasks to be done involving user interface design, networking code, database storage, novel algorithms... if you like systems programming and are looking for a project that's not "just another web app", then maybe monotone is for you. -For more information on the project generally, good places to start are the [http://monotone.ca homepage] and [http://monotone.ca/docs/ manual]. You might also want to browse over [http://cia.navi.cx/stats/project/monotone recent commits], or [http://news.gmane.org/gmane.comp.version%2dcontrol.monotone.devel recent mailing list posts]. To see the source, you can download a recent [http://monotone.ca/downloads/0.33/monotone-0.33.tar.gz release], and the file "HACKING" in the source has a number of useful tips on some of the more odd bits of monotone. +For more information on the project generally, good places to start are the [homepage](http://monotone.ca) and [manual](http://monotone.ca/docs/). You might also want to browse over [recent commits](http://cia.navi.cx/stats/project/monotone), or [recent mailing list posts](http://news.gmane.org/gmane.comp.version%2dcontrol.monotone.devel). To see the source, you can download a recent [release](http://monotone.ca/downloads/0.33/monotone-0.33.tar.gz), and the file "HACKING" in the source has a number of useful tips on some of the more odd bits of monotone. -If you have any questions, or just want to chat, then our IRC channel (#monotone on `irc.oftc.net`, NOT on freenode, or you may be able to use this link: irc://irc.oftc.net/#monotone) is always open -- though depending on the time of day, you might have to hang around for a bit for someone to turn up and notice your question. And, of course, there's always the [http://mail.nongnu.org/mailman/listinfo/monotone-devel mailing list]. +If you have any questions, or just want to chat, then our IRC channel (#monotone on `irc.oftc.net`, NOT on freenode, or you may be able to use this link: irc://irc.oftc.net/#monotone) is always open -- though depending on the time of day, you might have to hang around for a bit for someone to turn up and notice your question. And, of course, there's always the [mailing list](http://mail.nongnu.org/mailman/listinfo/monotone-devel). -= Project ideas = +# Project ideas The classic model for a Summer of Code project is a complete new program or module, that one student starts writing at the beginning of the summer, and finishes at the end. It's our experience, though, that this is totally unlike how we actually write software. We all work on a single (and relatively small by lines-of-code) program, and whenever we think of a change we want to make, the very first question is how we can break it down into small independent changes, so that we can distribute the work and get our initial work into a release as soon as possible. As far as we're concerned, the whole point of Summer of Code is to get you participating in this communal effort and learning how this kind of software actually gets written. So this year we're trying an experiment. Instead of putting up a bunch of giant projects and telling you to pick 1, we're putting up a list of small to medium sized projects, and you get to pick several. Some of these (esp. at the top of the list) are quite simple and straightforward; some of them (esp. at the bottom of the list) require significant design effort and knowledge of monotone's architecture. (For your information, the magic word is "xyzzy"; see the application below for details.) We strongly recommend that you start with some easier projects and move on to harder ones; keep in mind that when you first start, you will have lots of things to figure out (how monotone's code is put together at all, how to write tests, how to submit patches, ...), and the easier projects are designed to help you figure that stuff out and prepare you for harder ones. -You can also propose to work on projects not on this list, but in that case we ''strongly'' recommend that you discuss your ideas with us first, on IRC or the mailing list. +You can also propose to work on projects not on this list, but in that case we *strongly* recommend that you discuss your ideas with us first, on IRC or the mailing list. - * '''`mtn edit-log`''': Like most VCSes, when you commit a revision in monotone it prompts you to describe your changes. In monotone, though, you don't actually have to wait until you commit -- if you prefer, you can describe your changes while you go, by editing the file _MTN/log. This project is simply to create a command that makes this more convenient -- instead of having to know the name of the internal log file, users can simply run this command and have an editor pop up, exactly as if they had typed `mtn commit`, just without any committing happening. (This task probably involves some cleanup of the code to edit commit messages, too, it's kind of grotty right now.) - * '''Support for `mtn attach`/`mtn detach`''': `mtn detach` removes bookkeeping information (i.e., the _MTN directory) from a workspace. `mtn attach` turns an existing directory into a workspace by creating a _MTN directory. This is useful, for instance, to people who repeatedly import other people's software (released as .tar.gz files) into monotone. - * '''Database access pattern visualization''': Speeding up monotone requires having really good insight into how it is accessing the database, because the most important factor in how fast we go is how well we utilize caching. Therefore, it would be nice to first instrument monotone to somehow output what files/rosters it is accessing in the database, and then build some scripts that display this information usefully. (For instance, by using graphviz to draw a graph, and then animating it.) - * '''Fix commit message output''': When you run `mtn commit`, a text editor pops up to let you describe your changes. Monotone automatically puts a description of those changes into the buffer, for you to refer to while writing your description. However, right now, that description is not very good -- it is the raw revision text that we will save to the database. We ''have'' code to generate a nice user-friendly description of changes -- it's what `mtn status` uses already. So the task is simply to make the message that comes up when you type `mtn commit` be the same as you would get if you typed `mtn status`. - * '''`mtn rename --guess`''': People sometimes rename files, but do it with `mv` or in their filemanager, instead of using `mtn rename`. This means that `mtn` doesn't know what has happened. Right now, they can fix things up after the fact by issuing a series of `mtn rename` commands describing each rename they actually did, but it would be convenient to have a command that figured out what had happened by itself, using heuristics. `mtn rename --guess` should look at what files have disappeared and what unknown files have appeared, and if they appear to be the same, internally issue a rename for them. - * '''`mtn clean`''': This command simply deletes unknown or ignored files from the workspace. - * '''Ignoring whitespace in diff''': It would be nice if monotone's internal diff could ignore whitespace changes on request. - * '''Commit message templates''': Some projects would like to set a template, so that when a user runs `mtn commit`, their text editor is pre-filled with some text. To implement this, pre-fill _MTN/log with the contents of the file `.mtn-template`, if it exists. - * '''Automatic updating of sample output in tutorial''': Our [http://monotone.ca/docs/Tutorial.html#Tutorial Tutorial] walks the user through a bunch of basic uses of monotone, showing commands and their outputs. But the outputs are always getting out of date, as we change monotone. Come up with some way to automatically go through the tutorial executing each command with the current version of monotone, and putting the current output into the file. (Note, you don't have to do this by parsing the .texi source directly, you could move the tutorial text out into another file that is easier to parse, and then generate the .texi from it.) - * '''Make our ssh-agent support work on win32''': We recently grew support for using ssh-agent for key storage and signing requests, but this so far only the code to talk to ssh-agent on POSIX-style systems has been written. We could support PuTTY's "Pageant" ssh-agent variant on Win32. This would involve looking at the source code for PuTTY to understand how PuTTY communicates with Pageant (to give you an idea, it uses the Windows thread message queues and shared memory) and writing our own implementation of this code so that we can talk to Pageant directly. - * '''Subversion importer''': Add code to monotone to read in [http://subversion.tigris.com Subversion] [http://svn.collab.net/viewvc/*checkout*/svn/trunk/notes/fs_dumprestore.txt dump format], and write it out to a monotone database. - * '''Remove boost::filesystem::path dependency''': boost::filesystem::path is a library that we use for some path handling and file io stuff. It is not very good, and it is one of our largest external dependencies. Fortunately, our use of it is mostly split off into a few files and insulated from the program, so it should not be ''too'' hard to replace it. (The most exciting part is writing a function that can take normalize arbitrary file paths.) - * '''Line-ending handling''': Many version control systems have a feature where you can arrange that certain files automagically change their line endings when they are checked out -- so, for instance, a source file could have unix-style line endings (LF) when checked out on unix, and windows-style line endings (CRLF) when checked out on windows. Add support for this feature to monotone. (This is requires coming up with a design for this feature that people can agree on, and some changes to how monotone access the workspace.) - * '''Output formatting support for `mtn automate`''': Monotone has lots of commands that are designed to be easy to use programmatically, from scripts or whatever. Many of them involve dumping lots of revision ids to the screen. Invent a simple templating language or some other sensible design, and arrange that users can, for instance, request that they see dates instead of revision ids when calling a certain command. (E.g., `mtn automate select h:net.venge.monotone --format='$date $author $revision'`, would print out, for each head of the branch `net.venge.monotone`, the date it was committed, the author, and the revision id. Or whatever the templating looked like, you get to design that part, this is just an example.) - * '''Selectors overhaul''': Monotone has a mini-language for referring to revisions, called [http://monotone.ca/docs/Selectors.html#Selectors selectors]. So, for instance, anywhere you specify a revision, you can use a hexadecimal id, or you can say something like `h:net.venge.monotone` to refer to the current head of the branch net.venge.monotone, or you could say `t:monotone-0.33` to refer to the revision with tag `monotone-0.33`, etc. This works well -- in fact, it works so well that we want to redo the current somewhat hacky and incomplete implementation and turn it into a more full-fledged and complete feature. There are lots of ideas for what exactly this would look like; you get to figure out which of them is best, get consensus from the community, and implement an interpreter for your new mini-language. - * '''Automate man page generation''': We recently deleted our manual page, because it had gotten ''so'' out of date that it was totally useless. We already maintain reference documentation in two places -- in the source code (for the use of `mtn --help`), and in the reference manual. Two places is enough. So this project is, add some code to monotone so that it can generate its own man page from the --help strings that are already in the binary, and modify the build system to automatically generate the man page in this way. - * '''Make netsync start up faster''': Right now, whenever you push your work to a server, or pull other people's latest work from a server (`mtn push`, `mtn pull`, `mtn sync`), there is an annoying pause while monotone builds some "merkle tries" in memory (these are a neat data structure that lets us do very efficient synchronization). Eliminate this pause, probably by creating some sort of efficient cache of them on disk. - * '''Redo subprocess pipe support on win32''': Monotone has code to spawn a child process and talk to its stdin/stdout, which it uses to implement, for instance, network synchronization over ssh. The code for this is really really elaborate and sucky, because there are two completely different implementations for unix and win32, and the win32 code is completely insane. This is because the win32 api is mostly insane, and we can't fix the win32 api, ''but'' we recently learned of a nice trick that would eliminate the insanity in this particular case, and make this code nice and simple and work the same way on both unix and win32. (Basically, the trick is to bind a port on localhost, connect to it over loopback, and then treat the two sockets the same way you treat the sockets that socketpair(2) gives you on a POSIX OS.) - * '''Synchronization over dumb protocols''': Right now, monotone can only synchronize to another monotone server, over its own special protocol. This causes annoyance for people who don't want to run another server, or who can't get to such a server because of firewalls, or who only have web hosting, etc. etc. So it would be nice if we could synchronize over protocols like HTTP and SFTP. Fortunately, we have a design for how to accomplish such synchronization, which exists in the `net.venge.monotone.dumb` branch, along with a prototype implementation in Python. Your job is to clean up the on-disk format into something sustainable long-term (some parts are a bit hacky right now), and start moving support for this kind of synchronization into monotone proper. In the ideal case, we end up with the ability to pull over HTTP and push/pull over SFTP directly from monotone. - * '''Log UI''': There are a lot of ways that `mtn log`'s user interface could be better (see, e.g., ["LogUI"]). Make it better. - * '''Conflict handling''': Sometimes, when you try to merge two revisions, there are conflicts. Right now, we do not have a nice way to write such conflicts into the workspace, and let the user deal with them. We do know pretty much how to accomplish this, but there's a bunch of code to be written to keep track of what conflicts exist, present them to the user, let the user deal with them, etc. - * '''.mtn-ignore cleanup''': `.mtn-ignore` is a file that lists patterns; any files in the workspace that match those patterns are considered "ignored". However, the code that implements this is (a) grotty, and split in a strange way between C++ and Lua, (b) using regular expressions for its patterns, while we decided at the MtnSummit that it should be some form of glob. Fix these issues. - * '''Grand unified workspace scan caching''': One of the bottleneck operations in a VCS is looking at the user's workspace and figuring out which files they have actually modified. This requires looking in some way at every file in the project (which may be 100,000+ files), and practically every interesting operation (`diff`, `status`, `commit`, `update`, ...) has to do this before it can do any useful work. Fortunately, there are a lot of optimizations that are possible, including scanning directories in just the right order, uses directory timestamps to detect the creation of new files or the deletion of old ones, etc. Right now, we do have a basic cache to detect changed files by using timestamps, called [http://monotone.ca/docs/Inodeprints.html#Inodeprints inodeprints]. However, it does not implement any of these advanced optimizations, and is not useful for detecting added or removed files. Implement this. + * **`mtn edit-log`**: Like most VCSes, when you commit a revision in monotone it prompts you to describe your changes. In monotone, though, you don't actually have to wait until you commit -- if you prefer, you can describe your changes while you go, by editing the file _MTN/log. This project is simply to create a command that makes this more convenient -- instead of having to know the name of the internal log file, users can simply run this command and have an editor pop up, exactly as if they had typed `mtn commit`, just without any committing happening. (This task probably involves some cleanup of the code to edit commit messages, too, it's kind of grotty right now.) + * **Support for `mtn attach`/`mtn detach`**: `mtn detach` removes bookkeeping information (i.e., the _MTN directory) from a workspace. `mtn attach` turns an existing directory into a workspace by creating a _MTN directory. This is useful, for instance, to people who repeatedly import other people's software (released as .tar.gz files) into monotone. + * **Database access pattern visualization**: Speeding up monotone requires having really good insight into how it is accessing the database, because the most important factor in how fast we go is how well we utilize caching. Therefore, it would be nice to first instrument monotone to somehow output what files/rosters it is accessing in the database, and then build some scripts that display this information usefully. (For instance, by using graphviz to draw a graph, and then animating it.) + * **Fix commit message output**: When you run `mtn commit`, a text editor pops up to let you describe your changes. Monotone automatically puts a description of those changes into the buffer, for you to refer to while writing your description. However, right now, that description is not very good -- it is the raw revision text that we will save to the database. We *have* code to generate a nice user-friendly description of changes -- it's what `mtn status` uses already. So the task is simply to make the message that comes up when you type `mtn commit` be the same as you would get if you typed `mtn status`. + * **`mtn rename --guess`**: People sometimes rename files, but do it with `mv` or in their filemanager, instead of using `mtn rename`. This means that `mtn` doesn't know what has happened. Right now, they can fix things up after the fact by issuing a series of `mtn rename` commands describing each rename they actually did, but it would be convenient to have a command that figured out what had happened by itself, using heuristics. `mtn rename --guess` should look at what files have disappeared and what unknown files have appeared, and if they appear to be the same, internally issue a rename for them. + * **`mtn clean`**: This command simply deletes unknown or ignored files from the workspace. + * **Ignoring whitespace in diff**: It would be nice if monotone's internal diff could ignore whitespace changes on request. + * **Commit message templates**: Some projects would like to set a template, so that when a user runs `mtn commit`, their text editor is pre-filled with some text. To implement this, pre-fill _MTN/log with the contents of the file `.mtn-template`, if it exists. + * **Automatic updating of sample output in tutorial**: Our [Tutorial](http://monotone.ca/docs/Tutorial.html#Tutorial) walks the user through a bunch of basic uses of monotone, showing commands and their outputs. But the outputs are always getting out of date, as we change monotone. Come up with some way to automatically go through the tutorial executing each command with the current version of monotone, and putting the current output into the file. (Note, you don't have to do this by parsing the .texi source directly, you could move the tutorial text out into another file that is easier to parse, and then generate the .texi from it.) + * **Make our ssh-agent support work on win32**: We recently grew support for using ssh-agent for key storage and signing requests, but this so far only the code to talk to ssh-agent on POSIX-style systems has been written. We could support [[PuTTY]]'s "Pageant" ssh-agent variant on Win32. This would involve looking at the source code for [[PuTTY]] to understand how [[PuTTY]] communicates with Pageant (to give you an idea, it uses the Windows thread message queues and shared memory) and writing our own implementation of this code so that we can talk to Pageant directly. + * **Subversion importer**: Add code to monotone to read in [Subversion](http://subversion.tigris.com) [dump format](http://svn.collab.net/viewvc/*checkout*/svn/trunk/notes/fs_dumprestore.txt), and write it out to a monotone database. + * **Remove boost::filesystem::path dependency**: boost::filesystem::path is a library that we use for some path handling and file io stuff. It is not very good, and it is one of our largest external dependencies. Fortunately, our use of it is mostly split off into a few files and insulated from the program, so it should not be *too* hard to replace it. (The most exciting part is writing a function that can take normalize arbitrary file paths.) + * **Line-ending handling**: Many version control systems have a feature where you can arrange that certain files automagically change their line endings when they are checked out -- so, for instance, a source file could have unix-style line endings (LF) when checked out on unix, and windows-style line endings (CRLF) when checked out on windows. Add support for this feature to monotone. (This is requires coming up with a design for this feature that people can agree on, and some changes to how monotone access the workspace.) + * **Output formatting support for `mtn automate`**: Monotone has lots of commands that are designed to be easy to use programmatically, from scripts or whatever. Many of them involve dumping lots of revision ids to the screen. Invent a simple templating language or some other sensible design, and arrange that users can, for instance, request that they see dates instead of revision ids when calling a certain command. (E.g., `mtn automate select h:net.venge.monotone --format='$date $author $revision'`, would print out, for each head of the branch `net.venge.monotone`, the date it was committed, the author, and the revision id. Or whatever the templating looked like, you get to design that part, this is just an example.) + * **Selectors overhaul**: Monotone has a mini-language for referring to revisions, called [selectors](http://monotone.ca/docs/Selectors.html#Selectors). So, for instance, anywhere you specify a revision, you can use a hexadecimal id, or you can say something like `h:net.venge.monotone` to refer to the current head of the branch net.venge.monotone, or you could say `t:monotone-0.33` to refer to the revision with tag `monotone-0.33`, etc. This works well -- in fact, it works so well that we want to redo the current somewhat hacky and incomplete implementation and turn it into a more full-fledged and complete feature. There are lots of ideas for what exactly this would look like; you get to figure out which of them is best, get consensus from the community, and implement an interpreter for your new mini-language. + * **Automate man page generation**: We recently deleted our manual page, because it had gotten *so* out of date that it was totally useless. We already maintain reference documentation in two places -- in the source code (for the use of `mtn --help`), and in the reference manual. Two places is enough. So this project is, add some code to monotone so that it can generate its own man page from the --help strings that are already in the binary, and modify the build system to automatically generate the man page in this way. + * **Make netsync start up faster**: Right now, whenever you push your work to a server, or pull other people's latest work from a server (`mtn push`, `mtn pull`, `mtn sync`), there is an annoying pause while monotone builds some "merkle tries" in memory (these are a neat data structure that lets us do very efficient synchronization). Eliminate this pause, probably by creating some sort of efficient cache of them on disk. + * **Redo subprocess pipe support on win32**: Monotone has code to spawn a child process and talk to its stdin/stdout, which it uses to implement, for instance, network synchronization over ssh. The code for this is really really elaborate and sucky, because there are two completely different implementations for unix and win32, and the win32 code is completely insane. This is because the win32 api is mostly insane, and we can't fix the win32 api, *but* we recently learned of a nice trick that would eliminate the insanity in this particular case, and make this code nice and simple and work the same way on both unix and win32. (Basically, the trick is to bind a port on localhost, connect to it over loopback, and then treat the two sockets the same way you treat the sockets that socketpair(2) gives you on a POSIX OS.) + * **Synchronization over dumb protocols**: Right now, monotone can only synchronize to another monotone server, over its own special protocol. This causes annoyance for people who don't want to run another server, or who can't get to such a server because of firewalls, or who only have web hosting, etc. etc. So it would be nice if we could synchronize over protocols like HTTP and SFTP. Fortunately, we have a design for how to accomplish such synchronization, which exists in the `net.venge.monotone.dumb` branch, along with a prototype implementation in Python. Your job is to clean up the on-disk format into something sustainable long-term (some parts are a bit hacky right now), and start moving support for this kind of synchronization into monotone proper. In the ideal case, we end up with the ability to pull over HTTP and push/pull over SFTP directly from monotone. + * **Log UI**: There are a lot of ways that `mtn log`'s user interface could be better (see, e.g., ["[[LogUI]]"]). Make it better. + * **Conflict handling**: Sometimes, when you try to merge two revisions, there are conflicts. Right now, we do not have a nice way to write such conflicts into the workspace, and let the user deal with them. We do know pretty much how to accomplish this, but there's a bunch of code to be written to keep track of what conflicts exist, present them to the user, let the user deal with them, etc. + * **.mtn-ignore cleanup**: `.mtn-ignore` is a file that lists patterns; any files in the workspace that match those patterns are considered "ignored". However, the code that implements this is (a) grotty, and split in a strange way between C++ and Lua, (b) using regular expressions for its patterns, while we decided at the [[MtnSummit]] that it should be some form of glob. Fix these issues. + * **Grand unified workspace scan caching**: One of the bottleneck operations in a VCS is looking at the user's workspace and figuring out which files they have actually modified. This requires looking in some way at every file in the project (which may be 100,000+ files), and practically every interesting operation (`diff`, `status`, `commit`, `update`, ...) has to do this before it can do any useful work. Fortunately, there are a lot of optimizations that are possible, including scanning directories in just the right order, uses directory timestamps to detect the creation of new files or the deletion of old ones, etc. Right now, we do have a basic cache to detect changed files by using timestamps, called [inodeprints](http://monotone.ca/docs/Inodeprints.html#Inodeprints). However, it does not implement any of these advanced optimizations, and is not useful for detecting added or removed files. Implement this. - * '''botan/ajisai''': Monotone currently uses [http://botan.randombit.net/ Botan] for its crypto requirements. It might be useful if we could use the in-development [http://randombit.net/projects/ajisai/ Ajisai] library for SSL of Netsync (see NetsyncTodo). ''TODO: find out what the status of Ajisai is.'' (Short answer: SSLv3/TLSv1.0 support, works, missing many features and doesn't support anything but BSD sockets). One immediate improvement to Botan would be making use of its assembly-code modules for SHA1 and big-number math routines - they would just need integration with Monotone's autoconf/automake-based build system. + * **botan/ajisai**: Monotone currently uses [Botan](http://botan.randombit.net/) for its crypto requirements. It might be useful if we could use the in-development [Ajisai](http://randombit.net/projects/ajisai/) library for SSL of Netsync (see [[NetsyncTodo]]). *TODO: find out what the status of Ajisai is.* (Short answer: SSLv3/TLSv1.0 support, works, missing many features and doesn't support anything but BSD sockets). One immediate improvement to Botan would be making use of its assembly-code modules for SHA1 and big-number math routines - they would just need integration with Monotone's autoconf/automake-based build system. -[http://guitone.thomaskeller.biz Guitone] is a front-end to monotone, written using C++ and [http://www.trolltech.com/products/qt Qt]. There some tasks that could also improve it: - * '''A graph view:''' guitone is still lacking a kick-ass graph view, one of the most demanded features. Possible C++/Qt libraries which could be used here include [http://www.libqanava.org/ libqanava], [http://www.tulip-software.org/ libtulip] or [http://www.graphviz.org/ graphviz]. - * '''A kpart module:''' Beside the stand-alone Qt applications there have been thoughts about creating a kpart add-in for KDE's konqueror. Implement this! - * '''A Windows Explorer Add-In:''' For Win32 there exist popular VCS frontends including TortoiseCVS for CVS and TortoiseSVN for Subversion which make it plain dead simple for users to deal with version control, by acting as Windows Explorer add-ins. We need one of these for monotone as well! - * '''A Win32 installer:''' Since the majority of guitone users are Win32 users it would be great to have a full-featured installer and uninstaller for the application. - * '''A new build system:''' This is for Python enthusiasts: [http://www.freehackers.org/~tnagy/bksys.html waf] is an alternative build system based on SCons which unfortunately not yet supports Win32 native builds. guitone probably needs some some more tweaks here and there to make this really rock (including further automation for creating all kinds of distribution packages). Work started in the [http://tracmtn.thomaskeller.biz/trac/browser/?rev=h:net.venge.monotone.guitone.waf net.venge.monotone.guitone.waf] branch. +[Guitone](http://guitone.thomaskeller.biz) is a front-end to monotone, written using C++ and [Qt](http://www.trolltech.com/products/qt). There some tasks that could also improve it: -= Questions for applicants = + * **A graph view:** guitone is still lacking a kick-ass graph view, one of the most demanded features. Possible C++/Qt libraries which could be used here include [libqanava](http://www.libqanava.org/), [libtulip](http://www.tulip-software.org/) or [graphviz](http://www.graphviz.org/). + * **A kpart module:** Beside the stand-alone Qt applications there have been thoughts about creating a kpart add-in for KDE's konqueror. Implement this! + * **A Windows Explorer Add-In:** For Win32 there exist popular VCS frontends including [[TortoiseCVS]] for CVS and [[TortoiseSVN]] for Subversion which make it plain dead simple for users to deal with version control, by acting as Windows Explorer add-ins. We need one of these for monotone as well! + * **A Win32 installer:** Since the majority of guitone users are Win32 users it would be great to have a full-featured installer and uninstaller for the application. + * **A new build system:** This is for Python enthusiasts: [waf](http://www.freehackers.org/~tnagy/bksys.html) is an alternative build system based on SCons which unfortunately not yet supports Win32 native builds. guitone probably needs some some more tweaks here and there to make this really rock (including further automation for creating all kinds of distribution packages). Work started in the [net.venge.monotone.guitone.waf](http://tracmtn.thomaskeller.biz/trac/browser/?rev=h:net.venge.monotone.guitone.waf) branch. -This is the application questionnaire which we have submitted to Google; when you apply through their website, they will ask you a number of generic questions, and then give you this template to complete: +# Questions for applicants -{{{ -(If you have any questions about this application form, you can try #monotone on irc.oftc.net via IRC or address@hidden via email for general questions, and address@hidden for private questions.) +This is the application questionnaire which we have submitted to Google; when you apply through their website, they will ask you a number of generic questions, and then give you this template to complete: -BACKGROUND: -Who are you, beyond some characters on a screen? Tell us a little about yourself. + (If you have any questions about this application form, you can try #monotone on irc.oftc.net via IRC or address@hidden via email for general questions, and address@hidden for private questions.) + + BACKGROUND: + Who are you, beyond some characters on a screen? Tell us a little about yourself. + + Why are you applying to SoC? What do you hope to get out of it? + + Why are you applying to monotone, instead of some other project? What about it appeals to you? + + We would very much like to read some code, even if it just for a school project or whatever. Please give a URL for some code you have written in the past (alternatively, email a .zip or .tar.gz file to address@hidden, and note here that you have done so): + + Have you talked to us already, for instance on IRC or the mailing list? If so, what nick/email did you use? (This is to help us match up the people we remember talking to with the apps on Google's site.) + + LOGISTICS: + What is your work schedule this summer? In particular, when do you anticipate starting work, will you be gone for any time during the summer, and roughly how much time do you anticipate spending on Summer of Code work each week? + + How can we contact you if we have questions about your application? Please include any or all of IRC nicks, email addresses, IM screennames, phone numbers, whatever you feel comfortable giving us (we will not make them public) and will allow us to reach you. + + We know that there is a lot of writing on our Summer of Code wiki page, but we wouldn't have written it all if we didn't think it was important. To show us that you've read that page, what is the magic word that is mentioned in parentheses at one point in the text? + + PLANS: + Please list the projects you plan to work on this summer, if accepted. At a minimum, this list should include what the projects are, how long you anticipate each will take, a breakdown of where that time will go, and what results you will achieve at each stage: + + Please list some places where the schedule you just gave could run into problems. Which do you think are the most likely, and what will you do to adjust if they do occur? + + Final question: Why should we choose you to receive money for doing the above work, rather than some other student? -Why are you applying to SoC? What do you hope to get out of it? +# What happens if I'm selected? -Why are you applying to monotone, instead of some other project? What about it appeals to you? +*TBD* +subscribe to mailing list, start lurking on IRC, requirement of weekly status updates, probably requirement that you complete or at least have code to show for one quickie *before* the actual start date of the program (per Leslie's comments that we can require some small amount of work before the first payment this year, but need to figure out what the official word on such things is), note that we don't actually expect that anyone will end up following their schedule exactly, we just want you to be working and engaging. Something about how we define "success". -We would very much like to read some code, even if it just for a school project or whatever. Please give a URL for some code you have written in the past (alternatively, email a .zip or .tar.gz file to address@hidden, and note here that you have done so): - -Have you talked to us already, for instance on IRC or the mailing list? If so, what nick/email did you use? (This is to help us match up the people we remember talking to with the apps on Google's site.) - -LOGISTICS: -What is your work schedule this summer? In particular, when do you anticipate starting work, will you be gone for any time during the summer, and roughly how much time do you anticipate spending on Summer of Code work each week? - -How can we contact you if we have questions about your application? Please include any or all of IRC nicks, email addresses, IM screennames, phone numbers, whatever you feel comfortable giving us (we will not make them public) and will allow us to reach you. - -We know that there is a lot of writing on our Summer of Code page at http://venge.net/monotone/wiki/SummerOfCode2007 , but we wouldn't have written it all if we didn't think it was important. To show us that you've read that page, what is the magic word that is mentioned in parentheses at one point in the text? - -PLANS: -Please list the projects you plan to work on this summer, if accepted. At a minimum, this list should include what the projects are, how long you anticipate each will take, a breakdown of where that time will go, and what results you will achieve at each stage: - -Please list some places where the schedule you just gave could run into problems. Which do you think are the most likely, and what will you do to adjust if they do occur? - -Final question: Why should we choose you to receive money for doing the above work, rather than some other student? -}}} - -= What happens if I'm selected? = - -''TBD'' - -subscribe to mailing list, start lurking on IRC, requirement of weekly status updates, probably requirement that you complete or at least have code to show for one quickie ''before'' the actual start date of the program (per Leslie's comments that we can require some small amount of work before the first payment this year, but need to figure out what the official word on such things is), note that we don't actually expect that anyone will end up following their schedule exactly, we just want you to be working and engaging. Something about how we define "success".