[Python-Dev] Python sprint mechanics

[Fernando Perez]

"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