Difference between revisions of "Category:SVN"

From Noah.org
Jump to navigationJump to search
m
 
(30 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:Engineering]]
 
[[Category:Engineering]]
Subversion has flaws and limitations, but it's a lot better than CVS and it's cheap. The low price tag doesn't reflect low quality or lack of support. There are not a lot of hidden maintenance costs that will raise the total cost of ownership. Most of the deficiencies are clear up front. Subversion does do distributed version control very well and merging is frustrating (out of the box, a few simple third-party tools make it tolerable). It is also difficult to automatically generate reports that graph changes.
 
  
== Subversion remote access ==
+
I use Subversion a lot because a lot of employers use it and I had a lot of experience with it in the past. It fixes many of the glaring flaws in CVS. The moto of Subersion used to be "CVS done right", but Linus Torvalds joked that there is no "right" way to do CVS right and now I agree. Subversion is useful and it is not the worst thing in the world (CVS), but it is fundamentally and conceptually broken. It's easy to use git in a similar workflow as Subversion (centralized repository) and even handicapped like that it outperforms Subversion and is just as easy to use (even easier and better when you consider merging). '''So... I am a convert to [http://git.or.cz/ git].'''
  
After playing with WEBDAV and SVN Server (http:// and svn://) I settled on using svn+ssh://. It is secure and it requires little or no setup or service to run on the host (besides sshd). I don't know why anyone would use anything else. With a few SSH keys it's as easy to use locally as it is to use remotely. It's dead simple and reliable.
+
Subversion has flaws and limitations, but it's better than CVS and it's cheap. The low price doesn't reflect low quality or lack of support. Subversion does not do distributed version control and merging is bad; although, a third-party tool makes merging a bit more tolerable. It is also difficult to automatically generate reports that graph changes. The problem is that all the commercial offerings are very expensive. ClearCase is expensive to buy and very difficult to maintain. It is complex. Perforce is probably better, but it is also expensive. It's hard to beat free!
 
 
== Subversion setup for team development ==
 
 
 
If you want to share a repository among several developers you will need to configure a few trivial things.
 
 
 
Create a user "svn" and create the repository under "svn". This assumes the "svn" user will have a home directory of /home/svn.
 
 
 
Add each developer to the svn group (usermod or edit /etc/group):
 
 
 
  usermod -a -G svn username
 
 
 
Make the svn repository group writable. In this example the repository is called 'src':
 
 
 
  chmod -R g+w /home/svn/src
 
 
 
Now each developer in the svn group can checkout a project using an svn+ssh URL to the repository:
 
 
 
  svn co svn+ssh://username@svn.example.com/home/svn/project
 
 
 
== Merging ==
 
 
 
Subversion merging is painful. It's confusing; it's not easy to visualize what is happening; and you have to manually keep track of the revision numbers between the sections you want to merge. But no one said that merging was supposed to be easy. Subversion is free, so less complaining and more work!
 
 
 
Before you do anything make sure your branch working copy is up to date and committed (`svn up` then `svn ci`).
 
 
 
Merging always happens to your working copy. You might merge between remote URL A and remote URL B, but the results of that merge is stored in your local working copy. This tends to confuse people at first. This is why you want to make sure you working copy is up to date and committed; otherwise, you will get a three way merge which can be even more confusing.
 
 
 
<pre>
 
  A      B
 
    \    /
 
    \  /
 
      \/ 
 
working copy
 
</pre>
 
 
 
=== Merging Enhancements with [http://www.orcaware.com/svn/wiki/Svnmerge.py svnmerge.py] ===
 
 
 
The standard Subversion distribution comes with a handy script called [http://www.orcaware.com/svn/wiki/Svnmerge.py 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.
 
 
 
By default it expects to be run in a branch working copy and to merge from the trunk down to the branch.
 
 
 
<pre>
 
svnmerge.py init
 
</pre>
 
 
 
But it can run in a trunk working copy and merge from any branch up to the trunk.
 
 
 
<pre>
 
svnmerge.py init BRANCH_URL
 
</pre>
 
 
 
=== 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:
 
 
 
<pre>
 
svn log --verbose --stop-on-copy svn+ssh://svn.example.com/home/svn/module/branches/project
 
</pre>
 
 
 
=== 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.
 
 
 
==== merge FROM branch TO trunk ====
 
 
 
Do this if you want to merge changes <em>from the branch to the trunk</em>.
 
 
 
In your <em>trunk working copy</em> run this command:
 
 
 
<pre>
 
svn merge -r 17:HEAD svn+ssh://svn.example.com/home/svn/module/branches/project
 
</pre>
 
 
 
==== merge FROM trunk TO branch ====
 
 
 
Do this if you want to merge changes <em>from the trunk to the branch</em>.
 
 
 
In your <em>branch working copy</em> run this command:
 
 
 
<pre>
 
svn merge -r 17:HEAD svn+ssh://svn.example.com/home/svn/module/trunk/project
 
</pre>
 
 
 
The tricky thing to remember 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 [http://www.orcaware.com/svn/wiki/Svnmerge.py 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:
 
 
 
<pre>
 
svn merge -rPREV:HEAD my_file.txt
 
</pre>
 
 
 
== 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.
 
 
 
<pre>
 
svn status | grep ^C | awk '{print $2}' | xargs svn resolved
 
</pre>
 
 
 
== Check log messages in a given date range ==
 
 
 
Revision specifications can take dates. The dates a put between {curly braces}. For example, the following shows the logs for a six month range:
 
 
 
  svn log -r {2006-12-25}:{2007-6-25} topip.py
 
 
 
== 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 tell you if there will be any conflicts or automatic merging. It will only show "M" or "*" (newer on server), which is misleading because you might 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.
 
 
 
Note that "svn merge" isn't <em>exactly</em> like "svn up", but for the purposes of detecting merges and conflicts before they happen it's close enough.
 
 
 
== 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 permission or ownership.
 
 
 
== 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. For this example you should be <strong>in</strong> the directory you want to add. That is, your current working directory should be the directory you want to add. Here we add /etc to an SVN repository.
 
 
 
<pre>
 
cd /etc
 
svn mkdir file://home/svn/root/trunk/etc -m"Created /etc"
 
svn checkout file://home/svn/root/trunk/etc/. .
 
svn add *
 
svn add .*
 
svn ci
 
</pre>
 
 
 
==  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").
 

Latest revision as of 18:31, 10 February 2009


I use Subversion a lot because a lot of employers use it and I had a lot of experience with it in the past. It fixes many of the glaring flaws in CVS. The moto of Subersion used to be "CVS done right", but Linus Torvalds joked that there is no "right" way to do CVS right and now I agree. Subversion is useful and it is not the worst thing in the world (CVS), but it is fundamentally and conceptually broken. It's easy to use git in a similar workflow as Subversion (centralized repository) and even handicapped like that it outperforms Subversion and is just as easy to use (even easier and better when you consider merging). So... I am a convert to git.

Subversion has flaws and limitations, but it's better than CVS and it's cheap. The low price doesn't reflect low quality or lack of support. Subversion does not do distributed version control and merging is bad; although, a third-party tool makes merging a bit more tolerable. It is also difficult to automatically generate reports that graph changes. The problem is that all the commercial offerings are very expensive. ClearCase is expensive to buy and very difficult to maintain. It is complex. Perforce is probably better, but it is also expensive. It's hard to beat free!

Pages in category "SVN"

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