Svn practices

This page is under review. This line will be removed after it is done.

This page gathered svn practices frequently used by contributors and committers. If you have any advice to this page, please feel free to update it or discuss your idea in ooo-dev mail list.

SVN Client 1.7 is recommanded to use for AOO development.

Read-only access

• Grab the whole source code from main trunk

svn co https://svn.apache.org/repos/asf/incubator/ooo/trunk aoo

• Grab a branch

svn co https://svn.apache.org/repos/asf/incubator/ooo/branches/AOO34/main/sw sw This gets the source code for sw (i.e. the writer module) from the AOO34 branch

• Get the latest changes into your working copy

execute 'svn update' in working directory. It is ooo or sw for above cases.

This command will attempt to merge the public changes with the local changes if any.

• Update to a specific revision

svn update -r xxxx

• Check changes history

svn log
svn log -v
svn log -r m
svn log filename

• Check changes & Create patch for specific revision

svn diff -r m:n > n.patch

Write access

• Check changes before committing them

svn status

and / or

svn diff

• Commit your changes

Don't forget to specify the list of files/dirs that are changed to avoid accidentally committing unwanted changes.

svn commit -m "comment" [filenames]

• Committing a patch

Prepare a commit-comment file (e.g. mychangelog.txt) by using the relevant parts of this template:

  Patch by:
  Suggested by:
  Found by:
  Review by:
  Tested by:

and then commit it by running either

svn commit -F mychangelog.txt [filenames]

• Update Bugzilla

Update [bugzilla] with revision information for cross reference when you are done with the commit

Working with branch

There at least two situations that you need work with branche. Change you will made is complicated or you want to share it with others during development.

You may also need work with brache created by others. For example, after AOO 3.4 is released, a branch for AOO 3.4.1 was created.

Instead of doing 'svn commit' twice, 'svn merge' should be used if you get a fix need be submitted to both the 3.4.1 branch and main line.

There are also other cases in which you don't want to commit in development mainline directly.

• How to create a branche

svn copy https://svn.apache.org/repos/asf/incubator/ooo/trunk \ https://svn.apache.org/repos/asf/incubator/ooo/branches/tocloading \ -m "Creating a private branch for toc loading of word document."

• Keep a branche in sync

Subversion is aware of the history of your branch and knows when it split away from the mainline. To perform a sync merge, first make sure your working copy of the branch is “clean”—that it has no local modifications reported by 'svn status'. Then simply run:

$ pwd /home/user/tocloading

$ svn merge ^/ooo/trunk

• Reintegrate a branche

When your new feature is done. It needs to be merged back to mainline. Before do that, sync the brache with mainline and commit your changes. Then

$ svn merge --reintegrate ^/ooo/branches/tocloading

and commit again

• Remove a branche

Once a branche is integrated back. It is useless and can be removed.

$ svn delete ^/ooo/branches/tocloading -m "Remove branche of toc loading"

Reference

A guide for new committers: http://www.apache.org/dev/new-committers-guide.html

Merge Instruction from FreeBSD: http://wiki.freebsd.org/SubversionPrimer/Merging

SVN book: http://svnbook.red-bean.com/en/1.7/svn-book.html

SVN Best Practices http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html