Changes

The development source code of GRAMPS Gramps is stored in the SVN (Subversion) repository at sourceforge  

 This helps synchronizing changes from various developers, tracking changes, managing releases, etc. If you are reading this, you probablywant to do one of two things with SVN: either download the latest source or the development version, or else upload your changes (if you have write access to the repository) or [[Brief_introduction_to_SVN#Making_a_patchfile|make a patchfile ]] (if you don't have write access). * All developers should read Gramps [[Committing policies]]

* ''trunk'' - There is only one trunk. All new feature development happens in the trunk. New releases never come from the trunk. The trunk for GRAMPS Gramps can be found here: http://svn.code.sf.net/p/gramps/code/trunk

Release tags are created in the ''tags'' directory. The first two digits of the GRAMPS 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).

Imagine that the current version of GRAMPS Gramps is 8.3.2. A new series of features has been added in trunk and are ready for release. A new maintenance branch is created from trunk named 8.4 (or possibly 9.0 depending on the nature of the new features). New features continue to be added in trunk that will not be included in the 8.4 series of releases, but will be included in the 8.5 series. Bug fixes continue to occur in the 8.4 branch until the code is deemed worthy of release. At that time, a release is tagged from the 8.4 maintenance branch and named 8.4.0. Some time after the release of 8.4.0, some bugs are found and fixed in the 8.4 maintenance branch. Those bug fixes are released as 8.4.1.

:Also see: [[Getting started with GRAMPS Gramps Trunk]].

There are several versions of the gramps code in SVN.  

 If this talk of ''branch'' and ''trunk'' sounds confusing you might like to read the list message [http://articlesourceforge.gmane.orgnet/mailarchive/gmanemessage.comp.genealogy.gramps.devel/8678 php?msg_id=19238907 explaining branch and trunk].

To checkout a copy of the last branch GRAMPS Gramps 4.0 ./gramps40:

To checkout a copy of the last branch GRAMPS Gramps 3.4 ./gramps34:

To checkout a copy of the last branch GRAMPS Gramps 3.3 ./gramps33:

To checkout a copy of the last branch GRAMPS Gramps 3.2 ./gramps32:

To checkout a copy of the last branch GRAMPS Gramps 3.1 ./gramps31:

To checkout a copy of the older stable GRAMPS Gramps 3.0 ./gramps30:

To checkout a copy of the older stable GRAMPS Gramps 2.2 ./gramps22:

(Who is I? - I do not know how to make a patchfile which documents

will be a "svn patch" command which should do that. (Pat SVN 1.7 is out this is the link talk about [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.patch.html])

It is important that branches are removed once they have been mergedinto the trunk or have been abandoned. To remove a branch:

The developers reserve the right to remove branches that have beendormant for more than 1 year. 

Adding files to repositories requires you to set some properties to the files and to have a [http://apps.sourceforge.net/trac/sitedocs/wiki/Subversion sourceforge account]. See <code>svn help propset</code>. You can use the <code>propget</code> on existing files to see how you should add it. A convenient way is to add common files to your <code>~/.subversion/config</code> file, eg in my config I have:

The GRAMPS Gramps project does not keep a ChangeLog file under source control. All change history is captured by Subversion automatically when it is committed. A ChangeLog file is generated from the SVN commit logs before each release using [[How to use svn2clBrief_introduction_to_SVN#How_to_use_svn2cl|svn2cl]]. Developers should take care to make useful commit log messages when committing changes to Subversion. Here are some guidelines:

=== Other usage tips =How to use svn2cl ==== Starting with Gramps 3.0.0, we no longer have a <tt>ChangeLog</tt> file.  Instead, the list of changes is generated automatically using the standard <tt>svn2cl</tt> script. Note that <tt>svn2cl</tt> is not included in the base installation of subversion. With a Debian-based distro such as Ubuntu, you can get <tt>svn2cl</tt> as follows:  sudo apt-get install subversion-toolsor sudo apt-get install svn2cl There typically are two <tt>ChangeLog</tt> files needed for releases; one in the main directory, and one in the <tt>po</tt> directory. You can generate these files with the following commands:  cd gramps30 svn2cl --reparagraph --include-rev --authors=src/data/authors.xml cd po svn2cl --reparagraph --include-rev --authors=../src/data/authors.xml ===SVN Commit Tips======= Some procedural recommendations ==== # Always do ''svn up'' before a commit, and look especially for conflicts marked 'C'. If necessary get advice about handling conflicts.# Always do ''svn st'' and look for modifications 'M' that are unexpected or unintended. This is a *very important* sanity check. Checking the '?'reports for forgotten additions is also worth remembering.# Recommeded to explicitly name commit targets via 'svn ci X Y Z ..', but if you do simply 'svn ci' (or use a utility commit script), it is especially important to:## check advisory (2)## quit (no save) your edit session if you see a filename you did not expect -- svn will prompt whether you want to abort or commit without a log entry (say 'abort'). ;And here are a couple of incidental suggestions * avoid grouping unrelated changes; better to divide into separate commits for the following reasons: a better log entry; easier troubleshooting/reverting. (and probably more). * similar to above, it may be better to make small incremental changes than one big one (if possible). Interim changes should not introduce breakage, of course. * logs are important -- please give some thought to the log message: the ideal first sentence would be short, meaningful, and suggestive. Include a tracker issue #NNNN there, if appropriate. Additional explanation is encouraged if it would be something you yourself would appreciate when reading it six months from now. If relevant, emphasize impact of change from user's point of view. ==== svn merge ==== If you do a change in a branch, you need to do the same change in trunk. You can create a patch on the branch with svn diff > mypatch.patchand then apply the same patch on trunk. patch -p0 < mypatch.patch There is a more convenient way though: use svn merge. For this you commit your changes in the branch, and write down the revision number, eg a commit in branch{{stable_branch}} : Transmitting file data .. Committed revision 12345.Now you apply this change in branch{{stable_branch}} to trunk as follows. Go into your trunk working branch, and there type the command:  svn merge -c 12345 https://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps{{stable_branch}} The change will then be obtained and applied, after which you can commit trunk. 

=== Download Tarball =External links==*[http://subversion.apache.org/ Apache™ Subversion®]You can also download a tarball for past and present sources*[http://svnbook.red-bean. com/ Version Control with Subversion] '' This feature is no longer present *[http://www.clear.rice.edu/comp314/svn.html Source control in the new sourceforge platform ''ten minutes: a Subversion tutorial]