Changes

Jump to: navigation, search

Brief introduction to SVN

3,078 bytes added, 05:37, 9 February 2013
m
Download Tarball: no need to mention it
The development source code of Gramps is stored in the SVN repository at sourceforge
 
;[http://svn.code.sf.net/p/gramps/code/ http://svn.code.sf.net/p/gramps/code/].
 
This helps synchronizing changes from various developers, tracking changes, managing releases, etc. If you are reading this, you probably
want 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]]
== Types of branches ==
The development branch for small changes and bug fixes is ''gramps{{stable_branch}}'' and ''trunk'' has been created for the ongoing unstable version.
If this talk of ''branch'' and ''trunk'' sounds confusing you might like to read the list message [http://articlesourceforge.gmane.orgnet/mailarchive/gmane.comp.genealogymessage.gramps.devel/8678 php?msg_id=19238907 explaining branch and trunk].
'''Replace in the commands here ''https'' by ''http'' if you do not have a sourceforge account.
to modify the corresponding Makefile.am file.
(Who is I? - I do not know how to make a patchfile which documents
a deleted file which "patch" will then correctly delete.
(If you know how, please add it here.) When SVN version 1.7
is released (scheduled for 1Q2011 as I write this), then there
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])
== Working with development branches ==
=== svn2cl ===
The 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:
*Try to make a descriptive message about the change.
*It is not necessary to put the names of the files you have modified in the commit message because Subversion stores that automatically.
=== 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. 
* Additional tips and recommendations related to committing changes: [[SVN Commit Tips]]
* Gramps [[Committing policies]]
=== Browse svn ===
the [http://sourceforge.net/p/gramps/code/ online interface].
=== Download Tarball ===
 
You can also download a tarball for past and present sources.
'' This feature is no longer present in the new sourceforge platform ''
[[Category:Developers/General|B]]

Navigation menu