Log in
Forgot your password?
History for ZopeSVNFAQ
??changed:- <h3>If you are new to subversion, the fist thing you should do is to read the first four chapters of the "subversion book":http://svnbook.red-bean.com/ .</h3> This FAQ is an attempt to gather together much of the common wisdom for how developers (both internal and external) work with the Zope sources in Subversion. Many of the items apply to other areas in the Zope repository, in addition to the Zope area. - **But I don't know anything about subversion...!** The "subversion book":http://svnbook.red-bean.com/ provides an excellent introduction to subversion. There is also a "chapter for those who are already familiar with CVS":http://svnbook.red-bean.com/svnbook/apa.html - **Where can I get a client for my favourite OS?** You can find the sources and packages for !RedHat, !SuSE, Mandrake, !FreeBSD, and Windows at "the subversion download homepage.":http://subversion.tigris.org/project_packages.html Subversion is also available in Debian GNU/Linux ('apt-get install subversion') as well as in "Fink":http://fink.sourceforge.net/ for MacOSX ( "View all available packages":http://fink.sourceforge.net/pdb/search.php?s=svn . To install the client binary package: 'apt-get install svn-client-ssl' ). If you're using Windows and would like to have integration into the Windows Explorer, take a look at "TortoiseSVN.":http://tortoisesvn.tigris.org/ - **How should I configure subversion** It is **VERY IMPORTANT** that you configure subversion to set line endings. See SubversionConfigurationForLineEndings When you are configuring subversion to set line endings, you should probably also set subversion to ignore '.pyc' and '.pyo' files by setting the 'global-ignores' option in your subversion configuration file. - **Can I get to the repository from a web browser** Of course: http://svn.zope.org/ - **How do I check out Zope?** Most people have read-only access - see ReadOnlyAccess for instructions:: svn co svn://svn.zope.org/repos/main/Zope/trunk Zope For those with write privileges, see WriteAccess. The quick hint, if you've got all the incidentals in place (and replacing 'myaccount' with your zope.org account name):: svn co svn+ssh://[email protected]/repos/main/Zope/trunk Zope Note that if your client user name is the same as your zope.org account name, you can omit the account name from the URL. See the **important note on SubversionConfigurationForLineEndings**. o **What are revision numbers?** Subversion assigns revision numbers to the repository as a whole. When you check in a change to subversion, you are incrementing the revision number for the respository as a whole. See: http://svnbook.red-bean.com/svnbook/ch02s03.html#svn-ch-2-sect-3.2 o **Why do examples sometimes use svn !URLs and sometimes use svn+ssh !URLs ? ** If you have write access to the subversion repository, you can use 'svn+ssh' !URLs all the time, however, when you are doing a read-only operation, you can use 'svn' !URLs, which happens to be a bit faster, puts less load on the server, and requires less typing. When doing things like logs and diffs using server data, we'll generally use 'svn' !URLs. o **What do you mean by "the trunk"?** The trunk is the main line of development from which major Zope releases are made. It is very important that the trunk remain stable so that releases can be made on short notice. To keep the trunk from becoming unstable, all work on Zope 2 is done on *branches* and when the work has stabilized it can be merged into the trunk. For more information on this see the ZopeReleasePolicy document, which talks more about how our releases are made and why it is important for the trunk to remain stable. Note that Zope 3 uses a slightly different approach. The trunk must **always** be stable. We use extensive automated testing to assure that the trunk is always stable. All code checked in must have automated tests and all zope automated tests must be run without error before checking anything in on the trunk. Because of these practices, most development in Zope 3 actually takes place on the trunk. See the last FAQ for more information. o **So does that mean I shouldn't check things directly into the Zope 2 trunk?** Right - for Zope 2 we are using the "activity branch" model for coordinating work on the Zope core. This means that you make a new branch to work on a given "activity" (like add a set of features or fixing bugs). When the work is complete, tested and stable the changes in that activity branch are merged into the trunk (and possibly into another branch from which third-dot bug fix releases are made). More information on the activity branch pattern (as well as a lot of good info on configuration management in general) is available at <a href="http://www.enteract.com/~bradapp/acme/branching/branch-creation.html#BranchPerTask">Streamed Lines</a>. o **Ok, so when am I supposed to make a branch in Zope 2?** For Zope 2, any discrete activity that will result in code changes should have its own branch. For example, "adding FTP and DAV support to SQLMethods" is a feature-adding activity and a branch should be made for it. "Fixing bugs in MailHost" is an example of a bug-fixing activity that should be done on a branch. Even "fixing collector issue #2020" can be an activity that is on a branch. o **What? Make a branch for a single bug fix? Are you licking toads?** It may seem like overkill, especially if you are new to using branches to coordinate a large amount of activity in a codebase, but you find in practice that this will actually make your life *easier*, not harder. Why? Suppose there is this bug that you want to fix. *You cannot just check out the trunk, commit the fix and forget it*. The reason you can't is that there is usually another branch besides the trunk that incremental bug-fix releases are being made from, and that branch needs to get the bug fix too. Technically you could check out a sandbox on the current major-release branch and commit the fix on that branch by hand just like you did for the trunk. In practice it is very easy to make mistakes doing it this way. Once you get the hang of working on branches and merging your work into other branches you will find that it is much faster and much less error-prone to make even small changes by doing them in an activity branch. o **Can I work on both bug-fixes and features in the same activity branch?** It is almost always best to seperate bug-fix and new feature work into separate branches. The reason is that new features (once they are tested and stable) should be merged into the *trunk only*. Bug fixes need to be merged into *both the trunk and the current release branch* (so that subsequent incremental bug-fix releases will include them). While it is not impossible to do selective (file-by-file) merging to make sure that bugs and features get merged into the right places, it is much easier to just use separate branches. o **How do I find out what the current release branch is?** A new "release branch" is created when a new-feature release of Zope goes into its first beta. The name of the release branch created is based on major and minor version numbers of the release. For example, when Zope 2.8 goes into beta, a branch named 'Zope-2.8' is created and subsequent releases in the 2.8 line are created from the 'Zope-2.8' branch. You can usually do:: svn ls svn://svn.zope.org/repos/main/Zope/branches to get a list of the branches and see the highest 'Zope-x.y' tag listed to figure out the current release branch. If you are not sure, ask someone! o **So how do I make a branch for my work?** See: http://svnbook.red-bean.com/svnbook/ch04.html . To create a sandbox on an activity branch, copy the trunk to a branch:: svn copy -m 'Making Zope 2.8 branch' \ svn+ssh://[email protected]/repos/main/Zope/trunk \ svn+ssh://[email protected]/repos/main/Zope/branches/mybranchname Then checkout your branch:: svn co svn+ssh://[email protected]/repos/main/Zope/branches/mybranchname o **How should I name branches I create?** The convention that we want to use is that *your name*, and a descriptive element be used in branch names. Using your name or login id as part of your branch tag names will help avoid name collisions. Some examples of good branch names:: brian-dav_level2_support amos-new_help_system [278 more lines...]