FrontPage
The Zope Public Subversion Repository
Contact: KenManheimer
Our public subversion repository (see http://svn.zope.org for a web view) provides read-only and selective write access to the source code for Zope's and related projects. Public SVN access and co-development with the community are critical to Zope's evolution.
Some Zope and Zope product development is hosted using CVS, especially the Zope 2.7 development branch and older versions. Please see the CVS information page for more information on the CVS repository.
See SVNResources for pointers to SVN background information, and ZopeSVNFAQ for instructions on key SVN operations for use with our repository.
- ReadOnlyAccess describes how to to hookup with the SVN repository to track changes.
- RepositoryProjects describes the projects in the repository, including information about their focus, managers, and checkin-notice distribution maillists so you can follow the checkins for the projects.
- See RepositoryOrganization for details about the structure and contents of our repository.
- http://svn.zope.org presents a web interface by which you can browse the repository - visit there for instructions.
- There are many ways to contribute - see GettingInvolved (non-wiki).
Zope Corp. developers and selected members of the community have write access to the repository.
- ImpatientPeoplesGuideToRequestingCommitPrivileges
- The Zope repository is now opened to checkins from the community. ContributorIntroduction gives background information on the approach. ContributorFAQ summarizes questions and answers. Finally, the Zope Contributor Agreement is the legal agreement that gets signed and returned.
- WriteAccess contains the policies and procedures for write-access to the SVN repository (and it contains CommitterGuidelines, required reading for anyone with write access).
- ZopeDevelopmentProcess provides details about the who, what, when and where of changing the Zope code. This is more detailed than the CommitterGuidelines, and talks about exactly where changes should go for features and bug fixes, relation to releases, etc.
- BugDays describes the "bug day" process we use to ensure that issues are addressed.