Jump to: navigation, search

Brief introduction to SVN

3,228 bytes added, 09:34, 7 August 2009
Added developer guidance for development branches.
* ''maintenance'' - There are many maintenance branches. A maintenance branch is created from the trunk when all the features for a release are complete. New features are not committed to maintenance branch. Releases only come from maintenance branches. The purpose of maintenance branches is to allow the line of code to stabilize while new features are added in trunk. Maintenance branches can be found here:
* ''geps'' - These are meant for development of [[Gramps Enhancement Proposals|Portal:Enhancement_Proposals]]. Most of the time GEPS are developed in the ''trunk''. Occassionally a GEP will require extensive reworking or long periods when the code base is ususable. In these cases a branch in ''geps'' can be used as a temporary development area. Once the hard work is done the change should be merged into the trunk and the ''geps'' branch should be removed. ''greps'' branches should follow the naming convention ''gep-<###>-<descriptive text>'' e.g. ''gep-013-server''. Please read the [[#Working with development branches]] section for help with managing these branches.
* ''sandbox'' - These are meant for experimentation purposes. If you want to explore some ideas or try out some changes that would break the ''trunk'' or prototype something that has not made it to a GEP you can create a ''sandbox'' branch. These should be short lived. As soon as you have finished please remove the branch. We reserve the right to remove any ''sandbox'' branch that has not been touched for 12 months. ''sandbox'' branches should use the following naming convention ''<username>-<descriptive text>'' e.g. ''hippy-prototype-rss-idea''. Please read the [[#Working with development branches]] section for help with managing these branches.
Release tags are created in the ''tags'' directory. The first two digits of the GRAMPS version number are reserved to indicate the maintenance branch the code came from. The last digit indicates the revision from that maintenance branch. For example, 3.0.4 would indicate the 5th release from the 3.0 branch (3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4).
=== Where for bugs? ===
The [ bug tracker] has in the right top angle different projects. Choose project 3.x and submit an issue.
== Working with development branches ==
If you are using a ''geps'' or ''sandbox'' branch you need to take care when merging changes from the ''trunk'' and back to the ''trunk''. Please take a few minutes to read the [| Basic Merging] section of the Subversion book.
'''IMPORTANT:''' please use an svn client that is version 1.5 or newer. The merge tracking functionality only became available in 1.5. If you use an earlier client you will have to deal with all the revision tracking of merges by hand - not fun.
'''IMPORTANT:''' if you see a message that talks about ''from foreign repository'' it is probably because your working copy was checked out from an http:// url but you are merging from a https:// url or visa versa. Just be consistent about why you use. Don't merge ''from foreign repository'' because svn will not be able to manage the revisions correctly.
Here is a quick crib sheet:
=== Creating a branch ===
To create a branch from the ''trunk'':
svn copy
=== Merging ''trunk'' changes into the branch ===
You should do this regularly so that you don't have a nasty job of resolving loads of conflicts when you come to merge your changes back into the ''trunk'':
cd gep-014-fab-feature
svn merge
'''NOTE''' you will see some modification to files that you are not expecting. If you look at these you will find that they are modifications to svn properties. These are used by the merging tool to keep track of what changes have already been applied.
=== Merging changes from the ''branch'' back into the ''trunk'' ===
When you are ready to merge your changes back into the ''trunk'':
First make sure you have all the ''trunk'' changes in your branch:
cd gep-014-fab-feature
svn merge
svn commit -m "meaningful message"
Then move over to a working copy of the ''trunk'' and merge in your branch:
cd trunk
svn merge --reintegrate
Now build it, test it, convince yourself that it all works and then commit the changes:
svn commit -m "All the changes for GEP-014"
Now you '''must''' delete your branch. You can recreate it later if you need to but svn can not cope with doing another merge --reintegrate from the same branch:
svn remove
=== Removing branches ===
It is important that branches are removed once they have been merged
into the trunk or have been abandoned. To remove a branch:
svn remove
The developers reserve the right to remove branches that have been
dormant for more than 1 year.
== Useful things to know ==

Navigation menu