Category:SVN

From Noah.org
Revision as of 04:15, 7 June 2007 by Root (talk | contribs) (New page: Category:Engineering == Subversion access == After playing with WEBDAV and SVN Server (http:// and svn://) I settled on using svn+ssh://. It is secure and it requires no setup or serv...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search


Subversion access

After playing with WEBDAV and SVN Server (http:// and svn://) I settled on using svn+ssh://. It is secure and it requires no setup or service to run on the host (besides sshd).

Merging

Subversion merging sucks. You have to manually keep track of the revision numbers between the sections you want to merge.

Before you do anything make sure your branch working copy is committed.

Merging Enhancements with svnmerge.py

The standard Subversion distribution comes with a handy script called svnmerge.py that keeps track each time you merge in either direction. This allows you to incrementally merge changes without having to manually keep track of revision numbers. Don't merge without it.

What revision was a branch created from?

Merging requires that you know at what revision a branch was branched from. When you did the "svn copy" the new branched copy got a logged with a revision number. This is tricky for a beginner because intuitively you expect Subversion to merge from one branch to another without requiring the user to keep track of branch revision numbers.

The easiest way to get the starting revision of a branch is this command:

svn log --verbose --stop-on-copy svn+ssh://svn.example.com/home/svn/module/branches/project

How to merge to or from the trunk

Use the trick above to get the revision you branched from. Assume this gives you a revision number 17 and assume that you want to merge changes from the branch to the trunk. Now on the trunk working copy issue this command:

svn merge -r 17:HEAD svn+ssh://svn.example.com/home/svn/module/branches/project

Often you want to keep your branch up to date with changes on the trunk. In your branch working copy run this command:

svn merge -r 17:HEAD svn+ssh://svn.example.com/home/svn/module/trunk/project

The trick here is that now your branch gets the latest Revision number. The next time you want to do an update from the trunk you need to use this new revision number! Yikes! Save yourself some trouble and use svnmerge.py.

Merge back to previous version

Sometimes you need to roll-back to a previous version after you have committed changes. For this you use merge. In the example below PREV and HEAD are aliases that svn interprets, so you don't even have to know the exact revision numbers you are merging from and to:

svn merge -rPREV:HEAD my_file.txt

Mass resolve

This does a resolve all. This will very likely result in a bunch of garbled files. All of the conflicted files will be mangled. But I found this useful from time to time when I know what I'm doing or if I am just going to "svn rm" a whole directory anway.

 svn status | grep ^C | awk '{print $2}' | xargs svn resolved

What is svn going to do to my files when I update?

It's annoying that "svn status" does not do this. The status command only looks at your local revisions. Even if you add '-u' and do "svn status -u" you will still not see if there will be any conflicts or automatic merging. It will only show "M", which is very misleading. You might now think that you can Update or Commit without conflicts. Here svn does not follow the principle of least surprise.

The solution is to use the merge command. The "svn up" command is just a special form of merging. You can use merge to do an update. The key is that "svn merge" supports the "--dry-run" option, so you can see what files would get thrashed before they actually get thrashed.

 svn merge --dry-run -r BASE:HEAD .

This would be a lot simpler if "svn up" supported "--dry-run" or if "svn status" did what you think it should do.

CR vs. CR/LF -- set text file line endings

This will recursively set all text files (will ignore binary files) so that svn will change text file line endings on checkout.

 svn propset -R svn:eol-style native *

Set to always CR (UNIX):

 svn propset -R svn:eol-style CR *

Set to always CRLF (Windows):

 svn propset -R svn:eol-style CRLF *

Keywords

This sets keyword expansion for the Id keyword.

 svn propset svn:keywords Id *

Put $Id$ in your code and it will be expanded to something like:

 $Id: calc.c 148 2002-07-28 21:30:43Z sally $

Execute permissions

This sets execute permission on "script.sh":

 svn propset svn:executable script.sh

Note that you cannot set read and write properties.

Error: Cannot replace a directory from within

If you see this it probably means that your project directory was moved. If you have checked out the directory above then usually going back to the root and running "svn up" will fix this (it will rename your project directory). But probably you did not checkout every directory above this project, so you can't go up and run 'svn up'. Don't panic.

 svn switch

You almost always need the relocate switch:

 svn switch --relocate

Create and checkout a directory in place of an existing directory

You want to add an existing directory to svn but you don't want to do "svn import ..."; delete the import directory; then checkout the directory back in-place where you had it to begin with. For example, say you want to add your /etc directory to svn.

svn mkdir file://home/svn/root/trunk/etc -m"Created /etc"
svn checkout file://home/svn/root/trunk/etc /etc
svn add *
svn add .*

Status codes

Subversion prints letter codes next to the filenames to indicate their status. You will see status when you do an update, merge, or status:

svn status:

 U
   This means that you have no changes to your working copy, but 
   the svn server has new changes that will update your working copy.
 G
   This means that you have changes to your working copy and 
   the svn server has new changes that will be merged automatically 
   into your working copy. BEWARE! SVN is writing code for you.
   I never trust this.
 C
   This means that you have changes to your working copy and
   the svn server has new changes that conflict with your changes.
   These changes cannot be merged automatically.
   Your working copy will now contain conflict markers (<<<<<<<), so
   it will be broken until you edit and fix the conflicts.
   You will also have to tell Subversion that the conflict is resolved
   ("svn resolved myfile.txt").

Pages in category "SVN"

The following 7 pages are in this category, out of 7 total.