wiki:SubversionFAQ
Last modified 8 years ago Last modified on 01/18/2011 11:12:57 AM

Subversion (SVN) FAQ

How do I get subversion to stop asking me for my password?

Use public key authentication as described in SubversionSsh. An older, less secure way to do this using passphraseless keys is described in Setting up SSH for Subversion on DocuShare.

How do I get subversion to stop warning me about object/library/compiled Python files?

One way is to set the "global-ignores" configuration variable in the "miscellany" section of your "~/.subversion/config" file to include filename patterns such as "*.o", "*.os", "*.so", and "*.pyc" so that these never show up in "svn status" output as added files.

This has the disadvantage of only suppressing warnings for you (but is a fine solution for things like .gdb_history files that you produced personally as opposed the LSST build system); a better way to solve the problem is to set the svn:ignore property, e.g. svn propedit svn:ignore test (followed by an svn ci).

See the Subversion documentation for more information.

How do I get subversion to stop warning me about other files?

Set the "svn:ignore" property on the directory containing those files using "svn propset" or "svn propedit". The value of the property is a list, one per line, of filename patterns that should be ignored. This is most useful for executables, Swig-generated wrapper code, and test outputs.

What if my code uses software somebody else is working on?

Generally the version on the trunk should be usable at all times, because development should be done in a ticket or branch. But if you need access to code that is in development you can check out the appropriate ticket (or branch) and update it when you know it's safe to do so, then use scons to install that checked-out software.

You may want to check the in-development code out into a separate directory, or you may want to use "svn switch" to change the version in an already checked-out directory. See the Subversion documentation for more information on why "switch" can be useful.

What if I need the other person's work on my branch?

Use merge. See next item.

How should I manage development, including merges?

(The previous documentation on svnmerge.py is now obsolete.)

In general, all code development work should be done on a ticket branch labeled by the number of the ticket requesting the work. This ticket branch is created from a "mainline" branch (either the trunk or a release branch) using "svn cp":

$ svn cp ^/DMS/{package}/trunk ^/DMS/{package}/tickets/{number} -m "Create branch for #{number}."
or
$ svn cp ^/DMS/{package}/branches/PT1 ^/DMS/{package}/tickets/{number} -m "Create branch for #{number}."

A working copy of the new ticket branch can be created either by checking it out into a new directory or by switching an existing working copy:

$ svn co ^/DMS/{package}/tickets/{number} {package}-{number}
$ cd {package}-{number}
or
$ cd {package}
$ svn switch ^/DMS/{package}/tickets/{number}

Changes should then be made in the ticket branch working copy, and those changes checked in periodically (making sure to include the ticket number in the checkin message):

[... make changes ...]
$ svn ci -m "Worked on fix.  #{number}"

From time to time, changes from the mainline branch may be incorporated into the still-under-development ticket branch using "svn merge":

$ svn merge ^/DMS/{package}/trunk
or
$ svn merge ^/DMS/{package}/branches/PT1
[must be the same mainline branch that the ticket branch was copied from]
[... resolve conflicts ...]
$ svn ci -m "Merged from trunk.  #{number}"

When all changes are complete, all tests pass on the ticket branch working copy, and the code has passed code and standards review, the ticket branch should be merged with the mainline branch using "svn merge --reintegrate". "--reintegrate" is required in order to properly handle trunk changes that had already been merged into the ticket branch. In this process, the working copy is switched to the mainline branch, the merge is done, any conflicts are resolved and the resulting working copy is checked back in to the mainline branch:

$ svn switch ^/DMS/{package}/trunk
or
$ svn switch ^/DMS/{package}/branches/PT1
[must be the same mainline branch that the ticket branch was copied from]

$ svn merge --reintegrate ^/DMS/{package}/tickets/{number}

$ svn ci -m "Merge ticket #{number} to trunk."
or
$ svn ci -m "Merge ticket #{number} to PT1 branch."
[produces rNNNNN]

Please note: the now-unusable ticket branch is not removed thus enabling convenient access to the ticket history; see: DM/Policy/SubversionTicketDirectoryRemoval.

If the same change needs to be made to another "mainline" branch, that branch can be switched to and the change merged to it using a "cherry-picking" "svn merge" command:

$ svn switch ^/DMS/{package}/branches/PT1
or
$ svn switch ^/DMS/{package}/trunk
[note that this is the opposite of where the ticket was copied from]

$ svn merge -c NNNNN ^/DMS/{package}/trunk
or
$ svn merge -c NNNNN ^/DMS/{package}/branches/PT1
[note that this is the same as where the ticket was copied from originally,
and the number is the revision number from the checkin of the ticket merge
to its mainline branch]

$ svn ci -m "Merge #{number} bug fix to PT2 trunk."

In summary: copy branch to ticket, change ticket, "merge --reintegrate" ticket to branch, "merge -c NNNN" branch to trunk. Or: copy trunk to ticket, change ticket, "merge --reintegrate" ticket to trunk, "merge -c NNNN" trunk to branch.

Merge diagram.

Attachments