[Python-Dev] Python sprint mechanics (original) (raw)

Fernando Perez fperez.net at gmail.com
Sat May 6 11:00:49 CEST 2006

"Martin v. Löwis" wrote:

Tim Peters wrote:

Since I hope we see a lot more of these problems in the future, what can be done to ease the pain? I don't know enough about SVN admin to know what might be realistic. Adding a pile of "temporary committers" comes to mind, but wouldn't really work since people will want to keep working on their branches after the sprint ends. Purely local SVN setups wouldn't work either, since sprint projects will generally have more than one worker bee, and they need to share code changes. I think Fredrik Lundh points to svk at such occasions.

Allow me to make a suggestion. A few months ago, Robert Kern (scipy dev) taught me a very neat trick for this kind of problem; we were going to hack on ipython together and wanted a quick way to share code without touching the main SVN repo (though both of us have commit rights). His solution was very simple, involving just twisted and bazaar-ng (Robert had some bad experiences with SVK, though I suppose you could use that as well).

I later had the occasion to test it on a multi-day sprint with other developers, and was extremely happy with the results. For that sprint, I documented the process here:

http://projects.scipy.org/neuroimaging/ni/wiki/SprintCodeSharing

You might find this useful. In combination with IP aliasing over a local subnet to create stable IPs, and a few named aliases in a little hosts file, a group of people can find each other's data in an extremely efficient way over a several days, sync back and forth as needed, etc. At the end of the sprint, the 'real' committers can evaluate how much of what got done they want to push to the upstream SVN servers.

I hope this helps, feel free to ask for further details.

Cheers,

f

More information about the Python-Dev mailing list