[[TOC]] **HISTORIC PAGE!!** Please refer to [[wiki:HowToGit]] == Getting development information and code history from SVN == * "!ChangeLog" style file: install and run [http://ch.tudelft.nl/~arthur/svn2cl/ svn2cl] * File history in SVN: {{{ cd path/to/directory/ svn log [file.c] # or time reverted: svn log [file.c] | tac }}} * Bug: svn2cl !ChangeLog loses file names at branch point. Problem and possible solution described here: https://lists.osgeo.org/pipermail/grass-dev/2008-April/037363.html and https://lists.osgeo.org/pipermail/grass-dev/2008-April/037366.html == Switch the repository == To switch from SVN 'trunk' (GRASS 7 development) to 'releasebranch_7_2' (GRASS 7.2.x release branch) use {{{ cd /path/to/your/local/copy/trunk # might be needed on more modern systems: # svn upgrade svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_2 }}} The switch command preserves local, uncommitted changes. However, it does not preserve timestamps (to keep timestamps, better get the actual [https://grass.osgeo.org/grass72/source/snapshot/ SVN source code snapshot]). To find other branch names, check [http://trac.osgeo.org/grass/browser/grass/branches/ here]. == Switch from http to https == - Only needed in special cases - To be able to merge new files between branches both branches will have to appear to be from the same master repository. Subversion does not recognize `http://` and `https://` to be the same. In those cases the following command can be given to reassign http to https: {{{ svn switch --relocate \ http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 \ https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 . }}} == Download source code tarball and switch to the releasebranch_7_2 == To speed up the download, you can simply fetch the compressed weekly SVN source code snapshot and update it: * Download [http://grass.osgeo.org/download/software/sources/#grass72 Weekly 7.2-svn snapshot] * Extract (example for a date): {{{ tar xvfz grass-7.2.svn_src_snapshot_2016_05_25.tar.gz mv grass-7.2.svn_src_snapshot_2016_05_25/ grass-7.2.svn/ cd grass-7.2.svn/ # on more modern systems needed: # svn upgrade svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_2 }}} Now you have based your local copy to the "releasebranch_7_2". For future updates it is sufficient to run "svn update" as usual. == SVN usage == **HISTORIC PAGE!** Please refer to HowToGit** * Overview: http://svnbook.red-bean.com/ * Help: {{{ svn help svn help up svn help mv ... }}} * Update from SVN server (update states: A=Added; D=Deleted; U=Updated; C=Conflict; G=merGed): {{{ svn up }}} * Check for uncommitted local changes on your disk (If no output here, then everything is already uploaded to SVN): {{{ svn status }}} * Verify local changes before submitting: {{{ svn diff }}} Commit local changes to SVN server: * submitting individual file(s): {{{ svn ci -m "Some useful comment" file1 [file2 ...] }}} * global commit of all changes (be careful here): {{{ svn ci -m "Some useful comment" }}} * Add new file to SVN repository: {{{ svn add file svn ci -m "Some useful comment" file }}} * Add new directory to SVN repository: {{{ svn add directory svn ci -m "Some useful comment" directory }}} * Remove file from SVN server (careful!): {{{ svn rm file svn ci -m "Some useful comment" file }}} * Move file to another directory (this is the cool feature of SVN): {{{ svn mv file ../some_dir/ cd .. svn ci -m "file moved ... reason ..." }}} === Checkout source code === * See DownloadSource (note that you have to check out source code from SVN '''separately''' for the '''core GRASS GIS''' and the '''addons''') === Before making changes === * Double check that you are using the latest revision of the development branch before embarking on any changes. Example: {{{ svn up raster/r.digit/ }}} === Local Diffs === '''Before committing a change or submitting a patch you should review the changes'''. Viewing a diff is a nice way to do that. It is preferable to keep your patches concise- needless whitespace changes or a mixture of tasks can make it difficult to spot subtle changes introduced by your change. View changes: {{{ svn diff raster/r.digit/ }}} Save patch to a file: (run from top dir not the module dir. There are many "main.c" and "description.html" files to choose from and without the directory name it is hard to figure out where your patch should be applied) {{{ svn diff raster/r.digit/ > fancy_new.diff }}} === Revisit previous Diffs === You can easily check previously checked in changes: {{{ http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.digit/main.c In upper left corner, click: Last Change Revision Log }}} In the source code browser directory listing you can click on a file's ''Rev'' column to see a list of all changes, then pick two versions of the file and view changes. By clicking on a revisions ''Chgset'' number you can see the changes that came with that commit (including changes to other files). By clicking on ''@Rev'' column on the "View changes" page you can see the state of the file at that revision. When following changes with the [http://trac.osgeo.org/grass/timeline Timeline] you can click on the revision [number] to view changes. You can get a unidiff from the small link at the bottom of each page, if you prefer that. See also the [wiki:DownloadSource#Onlinebrowseablelivewebinterfacestosourcecoderepository ViewVC web interface mirror] of the SVN repository. (ViewCVS) === Commits back into the repository === (must have [wiki:HowToContribute write access]) * SVN prefers "atomic commits", i.e. commit changes to all files affected by a change at the same time, not in a series of commits (one for each file). * '''Please make the {{{-m}}} commit log message meaningful'''. It is your chance to explain "why". If you refer to bug numbers in the form "#123" the Trac system will automatically create a link from the message to the bug report. The same is true for revision changes, e.g. "r12345". {{{ svn diff raster/r.digit/main.c | less svn commit raster/r.digit/main.c \ -m "r.digit: fix uninitialized variable bug #123 (merge r12345 from trunk)" }}} === Merge between branches (backporting) === Please see **[[wiki:HowToBackport]] for the procedure**. ''Old style (not recommended):'' ~~Run the command from within the target branch.~~ * ~~Example 1: pull a change from trunk into the 7.2 release branch:~~ {{{ ### OLD STYLE, see above for modern style #cd releasebranch_7_2/ #svn up raster/r.digit/ #svn merge -c 30749 https://svn.osgeo.org/grass/grass/trunk #svn diff raster/r.digit/main.c #svn commit raster/r.digit/main.c -m "fix bug #456: unsafe quoting (merge from trunk, r30749)" }}} ~~where {{{30749}}} is the revision number of the changeset you wish to backport.~~ * ~~Example 2: merge a change from the old 6.4 release branch into GRASS 7 (trunk):~~ {{{ ### OLD STYLE, see above for modern style #cd trunk/ #svn up raster/r.digit/ #svn merge -c 31154 https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 #svn diff raster/r.digit/main.c #svn commit raster/r.digit/main.c -m"clean up help page, option descriptions (merge from relbr64, r31154)" }}} === Forking and cloning and merging back === If you want to create a fork or clone of an existing module, use "svn copy", not e.g. "cp -r". Also the source should be repository URL rather than a working copy directory. E.g.: {{{ cd raster/ svn copy https://svn.osgeo.org/grass/grass/trunk/raster/r.watershed r.watershed.mfd }}} This way, you can merge the changes since the fork back into the original. Or if you decide to replace the original with the forked version, the fork will have inherited the original's history when it was created. Note: grass-addons/ is part of the same repository as grass/, so it's possible to copy, rename, merge, etc between grass-addons/ and grass/. === Moving modules between trunk and Addons repository === To shift modules between trunk and Addons repository, use you first to copy to maintain the original's history, then delete: '''1) From trunk to Addons:''' {{{ # run in trunk, we "push" code to grass-addons/grass7/: cd scripts/ svn copy i.fusion.brovey https://svn.osgeo.org/grass/grass-addons/grass7/imagery/ svn rm i.fusion.brovey # then # - update the parent Makefile and remove module from list # - cleanup gui/wxpython/xml/toolboxes.xml }}} Then you need to update the related parent Makefile(s). Also update [wiki:Grass7/NewFeatures] accordingly. '''2) From Addons to trunk:''' {{{ # run in trunk: cd scripts/ svn copy https://svn.osgeo.org/grass/grass-addons/grass7/imagery/i.pansharpen i.pansharpen # then # - update the parent Makefile and add module to list # - add new module to gui/wxpython/xml/toolboxes.xml # - add a file "DEPRECATED" to the module directory in Addons. }}} Also update [wiki:Grass7/NewFeatures] accordingly. === Non-recursive checkout === * SVN does not allow you to check out a single file at a time. Sometimes this can be awkward as it can force you to checkout the entire repository for the sake of changing one file in the top directory. Solution: do a {{{--non-recursive}}} checkout: {{{ svn checkout --non-recursive \ https://svn.osgeo.org/grass/grass-web/trunk/ trunk/ }}} === Reverting submitted changes === While 'svn revert' is used to revert local, unsubmitted changes, the procedure differs for code already in the SVN repository. Example: {{{ cd lib/external # note the negative revision number (that is which you want to undo): ## important: submit at top directory level of repo! svn merge -c -32526 https://svn.osgeo.org/grass/grass/trunk/ # verify and submit svn diff file(s) svn ci -m "Reverted to previous version... reason ..." file(s) }}} Here, 32526 is a revision which was undesired. Passing a negative revision to "svn merge -c" will "unmerge" the change(s). Reverting a single file can be done also like this: {{{ # get revision number svn log myfile | less # order: "-r bad:good" revision number svn merge -r 32526:32525 file # verify and submit svn diff file svn ci -m "Reverted to previous version ... reason ..." file }}} === File properties === SVN lets you set file properties. For example to get "$Date$" text in the html and man help pages automatically update the Date keyword. Keywords are given in a space delimited string, adding a keyword requires that you include the previous keywords. As always, check with "`svn diff`" before committing. See "`svn help`" and "`svn help propset`" for more information. See the source:grass/trunk/SUBMITTING file for a list of mime-types. See source:grass-addons/tools/module_svn_propset.sh for an experimental script to take care of some of this for you automatically. Some common tasks: {{{ svn propset svn:keywords "Date" description.html svn propset svn:executable ON g.script.sh svn propset svn:mime-type "image/jpeg" example.jpg svn propset svn:eol-style "native" main.c svn proplist ps/ps.map/prolog.ps svn propget svn:mime-type ps/ps.map/prolog.ps svn propset svn:ignore "OBJ.* *.tmp.html" . }}} === Logs === Example how to get SVN logs by date range: {{{ svn log -r '{2015-12-31}:{2016-01-16}' }}} == How to work with patches == * See: https://grasswiki.osgeo.org/wiki/Patches == See Also == * http://developer.r-project.org/SVNtips.html * [wiki:HowToContribute How to get GRASS-SVN write access] * http://developer.r-project.org/SVNtips.html