Contributing as a Non-Committer using Subversion

Even without commit access to the Zope Subversion repository (see Becoming a Committer), you can still use Subversion to contribute to Zope projects, using a read-only checkout of the project’s sources.

How-To: Get a Read-only Subversion Checkout

There are several top-level modules in the repository - chief among them is the Zope sources - we’ll use them for our example. You can browse them all at http://svn.zope.org/

Read-only access uses Subversion svnserve server. Here’s how you can do your initial checkout.

For a Zope 2 trunk checkout:

$ svn co svn://svn.zope.org/repos/main/Zope/trunk Zope

For a Zope 2.11 checkout:

$ svn co svn://svn.zope.org/repos/main/Zope/branches/2.11 Zope

For a Zope 2.10 checkout:

$ svn co svn://svn.zope.org/repos/main/Zope/branches/2.10 Zope

etc.

For a Zope 3 trunk checkout:

$ svn co svn://svn.zope.org/repos/main/Zope3/trunk Zope3

For a Zope 3.4 checkout:

$ svn co svn://svn.zope.org/repos/main/Zope3/branches/3.4 Zope3

How-To: Get a Read-only Checkout from a Subversion Mirror

The main Zope repository can also be checked out read-only over HTTP, http://svn.zope.org/repos/main/ . E.g.:

$ svn co http://svn.zope.org/svn/repos/Zope2/trunk.

The Deutschsprachige Zope User Group (DZUG) hosts another SVN mirror http://svn.zope.de that can be checked out over HTTP. E.g.:

$ svn co http://svn.zope.de/Zope2/trunk.

Using a SVN mirror over HTTP is convenient if you are behind a firewall which blocks the svnserve port.

Note

Some Zope projects pull-in other parts of the repository using svn:externals using the svn:// protocol. Checking out such a project over HTTP is problematic: you may even encounter timeouts.

You can also browse the official SVN repository through HTTP read-only through http://svn.zope.org/repos/main/ .

Working inside the Read-only Checkout

You should then be able to work inside your checkout, fixing a bug or adding a feature. You can use Subversion commands as normal, e.g.:

$ svn co svn://svn.zope.org/repos/main/zope.event/trunk event-trunk
$ cd event-trunk/
$ svn info
Path: .
URL: svn://svn.zope.org/repos/mainzope.event/trunk
Repository Root: svn://svn.zope.org/repos/main
...
Last Changed Date: 2010-03-26 16:21:39 -0400 (Fri, 26 Mar 2010)

Let’s say you wanted ot add a bit of explanation to the README.txt file:

$ vi README.txt
...

Subversion knows about the changes you made:

$ svn stat
M      README.txt
$ svn diff
Index: README.txt
===================================================================
--- README.txt       (revision 8276)
+++ README.txt       (working copy)
@@ -6,6 +6,8 @@

 - An event publishing system

+- BLAH, BLAH...
+
 - A very simple event-dispatching system on which more sophisticated
   event dispatching systems can be built. For example, a type-based
   event dispatching system that builds on ``zope.event`` can be found in

You can keep your checkout updated with ongoing changes, too:

$ svn up
U    docs/api.rst
U    docs/conf.py
Updated to revision 8673.

and you may have to deal with changes which conflict with those you have made.

However, because you are working in an anonymous, read-only checkout, you cannot commit your changes back to the repository.

$ svn commit -m "R00l da world."
svn: Commit failed (details follow):
svn: Authorizatino failed

Oops, is all your hard work in vain?

How-to: Submit a patch from your Subversion checkout

Once you have fixed the bug or added the feature in your checkout, double- check that you have touched all the bases (see Coding Standards and Layout and Conventions). All is well, the tests pass, you added documentation for your cool new feature, so it is time to submit the patch.

First, don’t try to cut and paste the output from svn diff into an e-mail message or a web-browser textarea: such operations usually end up mangling the line endings or other bits of the diff, and make it impossible to apply cleanly. The maintainer who has to do reconstructive surgery on such a victim may just give up and ignore the patch.

Avoiding the cut-and-paste train wreck is straightforward: just create the patch as a file:

$ svn diff > /tmp/zope.event-my_cool_feature.patch

And then send or upload that file as an attachment: mailers and web-browsers are nearly as good at leaving attachments alone as they are at destroying sensitive inline text!

The preferred place to submit patches is to the project’s Launchpad bug tracker (see Bug Trackers for Zope-related Projects for how to find your project’s tracker). You will need to register for a Launchpad account, but you should then be able to create a new issue and upload your patch file to it.

Good titles, descriptions, and other metadata on the issue should help it get the attention of the right maintainer for the project: if you don’t hear back fairly quickly, try asking on the appropriate IRC channel for your project (see Zope IRC Channels), or follow up to the project developers’ mailing list (see Zope Mailing Lists).