in Aachen, Germany
Today I am going to meet up with other Subversion developers to hack, talk, invent, fix, inspire.
For those who are volunteer contributors, who may have little time to devote to Subversion usually, the hackathon provides a few days to concentrate on their favourite improvements and fixes, and to bring their ideas together.
For me, employed by Assembla to improve Subversion’s support for modern cloud work flows, this gives me a chance to gather ideas from other developers, bounce my ideas off them and see where they lead, and find new inspirations and enthusiasm.
Shelving and Checkpointing is my focus right now — the ability to quickly save and restore work in progress, without having to commit it to the repository. My initial version of shelving was merged to trunk last week, and Assembla is helping to make it available for users to try. (Download it here — and please let us know what you want it to become.)
Now I have started on checkpointing, discussing the design on the dev mailing list and implementing it on the ‘shelve-checkpoint’ branch. One of the next bits of coding, that I may try to complete during the hackathon, is when restoring or ‘unshelving’ a saved change to make Subversion first check whether any of the files it will touch is already modified in the working copy, so it can warn me that applying the saved changes may conflict.
More important, though, is to come up with longer term directions. One high on my list is the ability to send a locally prepared change to a code review system, and later to commit a change that has been reviewed, like the popular ‘merge request’ or ‘pull request’ work flows. Systems built on top of Subversion including RhodeCode, Rietveld, and Assembla provide these merge-request work flows. What we have now is the opportunity to streamline and standardize how these work, making them more generally available and interoperable.
I wonder how my list of topics will have changed by the end of the week.Also on: