Getting development information and code history from SVN

  • "ChangeLog" style file: install and run svn2cl
  • File history in SVN:
    cd path/to/directory/
    svn log [file.c]

    # or time reverted:
    svn log [file.c] | tac

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

The switch command preserves local, uncommitted changes. However, it does not preserve timestamps (to keep timestamps, better get the actual SVN source code snapshot).

To find other branch names, check 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 \ \ .

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:

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

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

    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:
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 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 ViewVC web interface mirror of the SVN repository. (ViewCVS)

Commits back into the repository

(must have 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)

Run the command from within the target branch.

  • Example 1: pull a change from trunk into the 7.2 release branch:
    cd releasebranch_7_2/
    svn up raster/r.digit/
    svn merge -c 30749
    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):
    cd trunk/
    svn up raster/r.digit/
    svn merge -c 31154
    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 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
svn rm i.fusion.brovey

Then you need to update the related parent Makefile(s). Also update Grass7/NewFeatures accordingly.

2) From Addons to trunk:

# run in trunk:

cd scripts/
svn copy i.pansharpen

Then you need to 'svn rm' the module in Addons and to update the related parent Makefile(s). Also update 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 \ 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):
svn merge -c -32526

# 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/ 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
svn propset svn:mime-type "image/jpeg" example.jpg
svn propset svn:eol-style "native" main.c

svn proplist ps/
svn propget svn:mime-type ps/ 

svn propset svn:ignore "OBJ.*
*.tmp.html" .


Example how to get SVN logs by date range:

svn log -r '{2015-12-31}:{2016-01-16}'

How to work with patches

See Also

Last modified 2 months ago Last modified on Jan 29, 2017 6:24:08 AM