• View
• Edit
• History
• Print

Subversion

Resources

• NCEAS SVN Configuration information
• svnx Using svnx on the Mac

Installing Subversion

• Windows installation:
  • Cygwin - Windows command line client
  • Subeclipse - Eclipse/SVN plugin
  • WinCVS - Windows GUI Client
    • Windows 7 users have problems with: Tortoise SVN, try WinCVS instead.
  • Netbeans/SVN notes - It could be that NetBeans has SVN support out of the box
• Solaris Installation

Checking out Ptolemy II

• $PTII/doc/coding/eclipse.htm

SVN vs CVS

Below is a comparison between SVN and CVS. The first two colums were taken from the The Subversion Features List

SVN benefits to Kepler

• WebDAV
  • Access from behind firewalls works.
  • LDAP access is easier than named Unix accounts
  • WebDAV has finer grained access control
• Kepler found cvs2svn conversion to result in smaller modules, which is different than the ptII experience (see below).
• Easier to move and rename directories in svn and retain logs
• svnsync will make it easier because Kepler depends on ptII.

Building SVN under Solaris

See http://subversion.apache.org/source-code.html

We use FSFS for the backend, not Berkeley DB. See http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/2008-June/013097.html

Below are the steps to build subversion-1.7.2:

I was having various problems installing subversion-1.7.2 under Solaris so I tried autogen.sh

Problem: SSL negotiation failed: SSL disabled due to library version mismatch

http://www.svnforum.org/threads/35175-SSL-negotiation-failed-Secure-connection-truncated suggests: "So Mozilla, RapidSVN, and TortoiseSVN were all breaking because of the SSLCipherSuite setting (both the original Apache-supplied value, and another value recommended by QualysGuard)."

When I upgraded from httpd-2.2.20 to 2.2.22, I noticed that httpd-ssl.conf changed:

However, it looks like the problem is that /usr/local/lib had links to older versions of the openssl libraries.

Below are the steps to build Subversion-1.6.17:

See http://bill.sirinek.com/?p=83

Note that during the install step, I got:

However, I already have /usr/local/apr/lib installed, so I don't think this is an issue.

We need --with-ssl so that we avoid svnsync: SSL is not supported.

I tried --disable-nls so as to avoid

but that did not work

The link was failing in subversion-1.6.12:

One fix is to edit Makefile:

Another fix is to run ./configure --with-ssl --with-libs=/usr/local/ssh/lib in the serf directory.

Another fix is to add -L/usr/local/lib to the link lines before -lssl -lcrypto:

The real fix is to use export LDFLAGS=-L/usr/local/lib before running ./configure.

Updating OpenSSL from 0.9.8.g to 0.9.8.o:

The link was failing in subversion-1.4.5:

The fix was to edit Makefile and add the following to SVN_APR_LIBS:

and set LIBS:

Complaints against Subversion

• Is svn that much better than cvs? http://subversion.tigris.org says "Subversion is meant to be a better CVS, so it has most of CVS's features". Typical arguments used for svn over cvs:
  • Merging in svn is better than in cvs. How many people actually use branches?
  • It is easier to move files in svn than in cvs. This has some merit, but is it worth the effort?
• If svn is a better CVS, then why is the svn status command different than cvs status.
• It turns out that svn info provides some of the info of cvs status, but how do I determine if keyword substitution is occurring? Under cvs, the cvs status command says -kb. What about svn?
• Building the client requires way too many other packages. How can svn possibly stay secure if it depends on so many packages?
• Subversion can optionally use Apache for access. Enabling a web server on a machine that does not already have one makes the machine less secure.
• There is no decent svn Unix style man page. This is deliberate, see Bug 1508. This is not good. I want to know exactly what commands will work with a specific installation of SVN, not what the latest documentation for the latest version is.
• On the server, svn is a disk hog.
  • A gzipped tar file of the Ptolemy II cvs tree is 372.9 MB.
  • A gzipped tar file of the same tree after running the conversion from cvs to svn is 570MB.
• On the client, svn is a disk hog.
  • Under Linux, the checked out ptII cvs repository is 333Mb.
  • Under Windows, the checked out ptII ssh repository is 726Mb

• Some discussion about the problem:
  • SVN Docs: Revisions
  • Why rewrite the Subversion working copy? 4/08 discussion

• Problems with Eclipse clients Subversive and Subclipse.

A user wrote: "I found both Subversive and Subclipse painful; I had to perform significant repairs externally using TortoiseSVN. I even managed to get Subversive to delete a 10MB directory tree by mistake!"

"Both Subversive and Subclipse are very dangerous for CVS users. In CVS, folders do not have significant state so you can do what you like when you like. In SVN you MUST commit folder state immediately after committing file state. For instance if you add something to svn:ignore, you must commit the folder, otherwise you risk having an outgoing conflict between svn:ignore outgoing and child folder state incoming. Do not attempt to fix such a conflict with either of Subclipse or Subversive; you just dig a deeper hole. Use TortoiseSVN to get back to all green arrows."

"Unfortunately neither subclipse nor subversion have GUI state for folder state comparison so you get no clue as to why folders are in a mess. The GUI is generally inadequate in distinguishing between folder as content and folder as container of children."

• Another drawback with svn is that the modtimes of the files are not

preserved. When I do a cvs checkout, the modtimes of the files are preserved. This makes it much easier to see what has recently changed.

Here's the svn tree:

Here's the cvs tree:

Being able to quickly see which Java file was last updated in the cvs tree is a serious win.

Also, the ptII tree includes derived files that are generated by Autoconf, JavaCC and Antlr. If the commit times are not preserved, then the source file might have a mod time later than the derived file which means that either the tool must be run or else the build system must touch the derived file. This is gross. Why not just preserve the commit time?

Why doesn't svn preserve mod times?

• Ian Brown mentioned that TortoiseSVN has an option that does this:

Set filedates to the "last commit time"

This option tells TortoiseSVN to set the filedates to the last commit time when doing a checkout or an update. Otherwise TortoiseSVN will use the current date. If you are developing software it is generally best to use the current date because build systems normally look at the datestamps to decide which files need compiling. If you use "last commit time" and revert to an older file revision, your project may not compile as you expect it to.

• Re: [Issue 1445] checkout/export must set last-commit-timestamps - 2004 post that discusses the problem.
• SVN Book, Chapter 7, Advanced Topics - covers setting use-commit-times
  • use-commit-times can be set in the Subversion config file. The tricky part is finding that file. For me, under Cygwin, the file was $HOME/.subversion/config. Other places to look are c:/Documents and Settings/cxh/Application Data/Subversion/config. Make this change:
    ### Set use-commit-times to make checkout/update/switch/revert
    ### put last-committed timestamps on every file touched.
    use-commit-times = yes
    

    [$[Get Code]]

• svn2cl is slow. This is not a svn problem, but a problem with xsltproc. Running svn2cl on a the ptII tree takes 43 minutes. Running gnuify-changelog.pl takes 84 seconds. However, gnuify-changelog.pl does not include the names of the files that were committed.

Still, I miss cvs2cl, which had nice features like clumping non-atomic cvs commits into one block of commits. It is a drawback in svn log that the output is not similar to cvs log.

The developer of svn2cl said:

• Conversion from CVS lost a few files.
• Conversion from CVS requires --default-eol=native. Instead, it should just convert files they are in the tree. Why do I have to specify a native default?

Conversion from CVS

• ONLamp.com -- Converting from CVS to Subversion with cvs2svn (2005)
• cvs2svn - download and instructions

CVS to SVN conversion procedure

1. Download and install cvs2svn
2. Make sure that all the binary files (.pdf, .eps, .gif, .png) etc. in the cvs repo have -kb set.
3. Copy the ptII repository for testing. cvs2svn will not work remotely see the How can I convert a CVS repository to which I only have remote access?. On the cvs repository machine (source), I copied /user/cvs/CVSROOT and /users/cvs/ptII
    cd /home
    gtar -zcf ptII.tar.gz --exclude=commitlogs cvs/CVSROOT  cvs/ptII

   [$[Get Code]]
4. On a fast machine other than the CVS repository, run the command
   cd /tmp
   mkdir cxh
   cd cxh
   scp source:/home/ptII.tar.gz .
   tar -zxf ptII.tar.gz
   cd cvs2svn-2.4.0
   ./cvs2svn --default-eol=native --fallback-encoding=utf_8 -s /tmp/cxh/repos/ptII /tmp/cxh/cvs/ptII
   

   [$[Get Code]]
5. Then try out the repository
   cd /tmp/cxh
   mkdir tmp
   cd tmp
   svn checkout file:///tmp/cxh/repos/ptII/trunk
   

   [$[Get Code]]

Script to fix up cvs

Moving the ptpapers repo

I wanted to move the ptpapers repo from CVS to SVN. After doing so, I did a diff and realized that the pdf files in the cvs repo were not checked in with -kb.

So, I ran cvs admin -kb on the .pdf and .eps files

Problems

• Why do is --default-eol=native not the default? My repository CVS repository is fine with regard to the binary mode, yet the tool ignores this? That is like having cp ignore null characters in files because they might cause a NullPointerException. Sheesh.
• Problems with a file being in the Attic. This is a sign of corruption, see the cvs2svn faq. I just removed that attic file
• Problems with encoding. Some of the files in ptII/ptolemy/domains/wireless/demo/CooperativeTerminals/Attic/ have the character \222. The fix is to use --fallback-encoding=utf_8. The command to restart is

 ./cvs2svn --pass CleanMetadataPass --dry-run -s /tmp/cxh/repos/ptII /tmp/cxh/cvs/ptI

• vergil/graph/EditorDropTarget.java was still in svn, though it had been removed from cvs.

• ptII/vendors/jhdl/ptjhdllib/JHDL.jar did not get

added

Under Eclipse, a Cygwin ssh window flashes

With the default subeclipse installation I get a Cygwin ssh window flashing.

• $PTII/doc/coding/eclipse.htm

describes a fix which is to tell Subclipse to use SVNKit

• HowTo: Configure SVN+SSH with Subclipse on Windows describes using Tortoisesvn and setting the SVN_SSH variable to

The backslashes are important However, with this method, I have to type in my passwd everytime or otherwise setup Tortoisesvn to do the right thing

Using Subversion with a different ssh user name

The svn --username command line option does not work with ssh. To use ssh with a different username, edit or create ~/.ssh/config with

where yourlog is the login on the remote server. (A tip of the hat to Chad Humphries, see Using a different username with SVN+SSH)

An alternative is to use your remote login in the URL, for example:

To illustrate that --username does not work with, ssh I was able to set up svn to use a debugging ssh server as follows:

• On the svn server, start up sshd in debug mode on a non-standard port: /usr/lib/ssh/sshd -d -p 29934
• On the svn client, set SVN_SSH@ to use the same port: export SVN_SSH="ssh -p 29934"@@
• On the svn client, try to connect as a user other than yourlog by su-ing or sudo-ing to another account (I chose apache) and running:

(:source) svn co --username yourlog svn+ssh://source.eecs.berkeley.edu/chess/ptII/trunk ptII (:sourceend:)

Sadly, the --username argument has no effect on ssh, the output on the svn server will say something like:

If I restart sshd on the server with /usr/lib/ssh/sshd -d -p 29934 and then run

then the output on the svn server will say:

Subclipse vs Subversion

Two Eclipse plugins: Subclipse and Subversion Subclipse

• + Hosted on tigris.org, which is where Subversion is hosted.
• - Team -> Share Project does not allow multiple projects to be added to svn

Subversive

• + Hosted at the Eclipse site.
• + Team -> Share Project does allow multiple projects to be added to svn

Chess svn setup design issues

• Use svnserve instead of Apache. See http://svnbook.red-bean.com/en/1.4/svn.serverconfig.choosing.html#svn.serverconfig.choosing.svn-ssh
  • source.eecs does not currently run Apache for security reasons
  • We have ssh accounts already on source.eecs
• Note that setting up anonymous svn access requires only one repository, per machine, unlike what we do with cvs. See One svnserve, multiple repositories
• We use shortened urls like svn co svn+ssh://source.eecs.berkeley.edu/chess/ptII/trunk ptII. The way we do this is by creating links in / for chess and other directories. svnserve has a -r option, which sets the virtual root. We don't use that, because if we did, then paths in svn co svn+ssh://source.eecs.berkeley.edu/home/svn/chess/ptII/trunk would not work. Instead, we create links for in /.

Chess svn set up todo list

• Document set up of user directories with svnserve
• Nightly builds

Setting up anonymous access under Solaris

• Using Subversion, NetBeans IDE, and Sun Java System Web Server With Java ME describes creating /etc/init.d/svnserve, our version looks like

• We then create a link

• Set up the firewall.

1. Edit /etc/ipf/ipf.conf

1. Update the firewall: ipf -Fa /etc/ipf/ipf.conf

• Test the setup:

Setting up SVN Email

See How do I get email about each ptII SVN check in?

This is not well documented, so here goes.

The post-commit script is run after a commit. This script must be in the hooks/ directory of the repository on the server.

1. Go to the hooks/ directory and copy post-commit.tmpl
   cd /home/svn/chess/ptIIprivi/hooks
   cp post-commit.tmpl post-commit
   chmod a+x post-commit

   [$[Get Code]]
2. Edit post-commit so that it looks like:
   #!/bin/sh                                                                      
   # See post-commit.tmpl                                                          
   
   REPOS="$1"
   REV="$2"
   
   /export/home/svn/chess/local/commit-email.pl -h source.eecs.berkeley.edu "$REPOS" "$REV" devels@yourdomain

   [$[Get Code]]
   On the CHESS server, the address would be workgroup-cvs at chess.
3. Copy commit-email.pl from the subversion sources:
   cp /export/home1/root/tools/subversion-1.4.5/tools/hook-scripts/commit-email.pl .

   [$[Get Code]]

Setting up email for people with non-EECS addresses.

By default, source.eecs assumes everyone has an EECS.Berkeley.EDU address. If this is not the case, then as root on source:

1. Edit /etc/mail/sendmail.cf and add the user account to the C{E}root line
2. Edit /etc/mail/aliases and add an alias for the user account to the outside email address
3. Run newaliases
4. Restart sendmail with /usr/bin/pkill -HUP -x -u 0 sendmail
5. Check the alias with

Email problem

subversion: not sending emails any more suggests editing commit-email.pl and changing

to

Setting up web access

Installing Apache

1. Download Apache
2. Configure Apache. The INSTALL doc from the subversion sources says:
   At the top of the httpd-2.0 tree:
   
   $ ./buildconf
   $ ./configure --enable-dav --enable-so --enable-maintainer-mode
   
   The first arg says to build mod_dav.
   
   The second arg says to enable shared module support which is needed
   for a typical compile of mod_dav_svn (see below).
   
   The third arg says to include debugging information. If you
   built Subversion with --enable-maintainer-mode, then you should
   do the same for Apache; there can be problems if one was
   compiled with debugging and the other without.
   
   Note: if you have multiple db versions installed on your system,
   Apache might link to a different one than Subversion, causing
   failures when accessing the repository through Apache. To prevent
   this from happening, you have to tell Apache which db version to
   use and where to find db. Add --with-dbm=db4 and
   --with-berkeley-db=/usr/local/BerkeleyDB.4.2 to the configure
   line. Make sure this is the same db as the one Subversion uses.
   This note assumes you have installed Berkeley DB 4.2.52
   at its default locations. For more info about the db requirement,
   see section I.5.
   
   You may also want to include other modules in your build. Add
   --enable-ssl to turn on SSL support, and --enable-deflate to turn on
   compression support, for example. Consult the Apache documentation
   for more details.
   

   [$[Get Code]]
   The options I used were:
   ./configure --prefix=/usr/local/apache-2.2.16 --datadir=/home/www
   --enable-so --enable-ssl --enable-rewrite --with-ssl=/usr/local/ssl \
   --disable-ipv6 --with-included-apr --enable-dav

   [$[Get Code]]
3. Set the path so that /usr/bin/ln is in the path before /usr/ucb/ln, then make and install apache:
   export PATH=/usr/bin:${PATH}
   make >& make.out
   make install >& install.out

   [$[Get Code]]
4. Set up the startup scripts
   cd /etc/rc3.d
   ln -s ../init.d/apachectl S30apachectl
   ln -s ../init.d/apachectl K30apachectl
   cd ../rc0.d
   ln -s ../init.d/apachectl K30apachectl
   cd ../rc1.d
   ln -s ../init.d/apachectl K30apachectl

   [$[Get Code]]
5. Start up apache:
   /etc/init.d/apachectl start

   [$[Get Code]]
6. Verify that there is a web page at http://source.eecs.berkeley.edu
7. Edit /usr/local/apache/conf/httpd.conf:
   # Subversion
   LoadModule dav_svn_module modules/mod_dav_svn.so
   
   <Location /svn/chess>
   #
   # Note: The following must must be present to support
   # starting without SSL on platforms with no /dev/random equivalent
   # but a statically compiled-in mod_ssl.
   #
   <IfModule ssl_module>
   SSLRandomSeed startup builtin
   SSLRandomSeed connect builtin
   </IfModule>
   
   # Subversion
   LoadModule dav_svn_module modules/mod_dav_svn.so
   LoadModule authz_svn_module modules/mod_authz_svn.so
   
   <Location /svn/chess/ealpapers>
   DAV svn
   SVNPath /home/svn/chess/ealpapers
   #SVNParentPath /home/svn
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/local/svn-chess-passwd
   Require valid-user
   # For any operations other than these, require an authenticated user.
   #<LimitExcept>
   # Require valid-user
   #</LimitExcept>
   # User svn
   # Group svn
   </Location>
   <Location /svn/chess/ptII>
   DAV svn
   SVNPath /home/svn/chess/ptII
   #SVNParentPath /home/svn
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/local/svn-chess-passwd
   # For any operations other than these, require an authenticated user.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
   Require valid-user
   </LimitExcept>
   # User svn
   # Group svn
   </Location>
   
   <Location /svn/chess/triq>
   DAV svn
   SVNPath /home/svn/chess/triq
   #SVNParentPath /home/svn
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/local/svn-chess-passwd
   # For any operations other than these, require an authenticated user.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
   Require valid-user
   </LimitExcept>
   # User svn
   # Group svn
   </Location>
   
   <Location /svn/kepler>
   DAV svn
   SVNPath /export/home2/svn/kepler
   #SVNParentPath /export/home2/svn
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/local/svn-chess-passwd
   # For any operations other than these, require an authenticated user.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
   Require valid-user
   </LimitExcept>
   # User svn
   # Group svn
   </Location>
   
   <Location /svn/chess/ojdcheck>
   DAV svn
   SVNPath /home/svn/chess/ojdcheck
   #SVNParentPath /export/home2/svn
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/local/svn-chess-passwd
   # For any operations other than these, require an authenticated user.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
   Require valid-user
   </LimitExcept>
   # User svn
   # Group svn
   </Location>
   
   
   

   [$[Get Code]]

svn: Certificate is not issued by a trusted authority

The problem is that running svn sometimes not recognize authority.

TortoiseSVN does not have this problem. (Update: Windows 7 users have problems with: Tortoise SVN, try WinCVS instead.)

Versions of svn compiled using OpenSSH under Mac OS X and Solaris do have this problem.

The error is:

We could just blindly permanently accept the certificate, but this is really wrong since it is bad security hygiene. Finding the cause of the problem and possible solutions is of interest. Below are two workarounds, see also Ptolemy Bugzilla:139 Convert the Ptolemy II repository from CVS to SVN

Going to https://source.eecs.berkeley.edu/svn/chess/ptII/trunk in a web browser such as Firefox and examining the certificate does not indicate an error.

Editing ~/.subversion/servers

Kevin Miller's Blog Subversion and Certificate Authorities discusses editing ~/.subversion/servers and also a couple of patches to svn-1.5.

See also Making SVN trust a new root CA certificate

To modify ~/.subversion/servers, download a copy of the missing Certificate Authority (CA) file as follows

1. In Firefox, go to https://source.eecs.berkeley.edu
2. Click on the lock in the bottom right
3. In the Page Info window, select the Security Tab and then select View Certificate
4. Select Details and then select the top level CA, which will be something like Builtin Object Token VeriSign Class 3 Public Primary CA
5. Export the file as an X.509 PEM file
6. Use that file in ~/.subversion/servers for the ssl-authority-files value, for example:
   ssl-authority-files=/Users/cxh/tmp/BuiltinObjectToken:VerisignClass3PublicPrimaryCertificationAuthority
   

   [$[Get Code]]

However, the problem here is that we are downloading the CA file from the website we are trying to verify. Another workaround is to download the root CAs from Verisign. The file we are interested in is PCA3ss_v4.509.

To view the contents of the CA file:

Then adjust ~/.subversion/servers:

and do the checkout. At least here, we have the authority file downloaded from Verisign, so we can be fairly certain that svn repository has a legitimate certificate.

Fixing OpenSSL

It turns out that the problem is that svn is using OpenSSL. The OpenSSL FAQ question How can I set up a bundle of commercial root CA certificates? says

However, an updated version of that script can be found at http://www.opensource.apple.com/darwinsource/Current/apache_mod_ssl-690/mod_ssl/pkg.sslcfg/ca-bundle.pl To run this, download ca-bundle.pl and do

Running:

will return 0, which is correct.

See also http://svn.haxx.se/dev/archive-2006-06/0547.shtml - a note about this problem in the svn devel log, which points out http://curl.haxx.se/docs/caextract.html which includes cacert.pem.

Here's how to set up openssl on the Mac so that it does not prompt for accepting the certificate:

1. Download the root CAs from Verisign. The file we are interested in is PCA3ss_v4.509.
   openssl x509 -inform DER -in PCA3ss_v4.509 -out PCA3ss_v4.pem -outform PEM
   

   [$[Get Code]]
2. To view the contents of the CA
3. Become root with:
   sudo -
   

   [$[Get Code]]
   and copy PCA3ss_v4.pem:
   cp PCA3ss_v4.pem /System/Library/OpenSSL/certs
   

   [$[Get Code]]
   For details, see Chris Adams' Installing Custom Certificate Authorities for OpenSSL
4. Run the c_rehash command from OpenSSL:
   c_rehash /System/Library/OpenSSL/certs/
   

   [$[Get Code]]

The certificate authority will be present and svn users should not be prompted to accept the certificate from source.eecs. Also, the

should return

It would be nice if we could import all the Commercial CAs in one fell swoop.

Firewall and Proxy Problems

If you get:

RA layer request failed svn: OPTIONS of 'https://source.eecs.berkeley.edu/svn/chess': Could not resolve hostname `source.eecs.berkeley.edu': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for.

Or if the Apache error_log says Error writing base64 data: Connection reset by peer [500, #131] (the see http://svn.haxx.se/users/archive-2007-09/0388.shtml)

Then the problem is likely with a corporate firewall.

The first thing to try is to point your web browser at the SVN url. For example, try opening https://source.eecs.berkeley.edu/svn/chess/ptII/trunk, you should get a listing of the files at that location. If you do, then the problem is that the SVN client needs to have its proxy set, see the Subversion FAQ for details.

Under TortoiseSVN, you could try setting the TortoiseSVN proxy to match the proxy of your web browser. If you have a proxy autoconfiguration URL, then try entering the URL into your browser and analyzing the code to determine the name of your proxy machine.

Another thing to try is to edit the \Documents and Settings\user\Application Data\Subversion\servers file and add

(Many Thanks to Thomas Mandl and Thomas Huining Feng for the above)

Another possibility is discussed at http://groups.google.com/group/pyjamas-dev/browse_thread/thread/682bc1991c2326b6

Keyword Substitution and end of line issues

To enable keyword substition, such as $Id$ being changed to $Id: bif4.txt 7 2009-03-05 01:13:48Z cxh $, you need to set up ~/.subversion/config so that each file extension has the appropriate settings. See http://chess.eecs.berkeley.edu/ptexternal/nightly/doc/coding/eclipse.htm#Subversive for details which involve adding ~/ptII/doc/coding/svn-config-auto-props.txt to ~/.subversion/config

Why is it necessary to add have a pattern for every file? The answer is that Subversion decides that everything is a binary file and that it is safer to check things in and not modify them. However, there should be a repository wide way to set up config instead of requiring each user to do so.

Another limitation is that the enable-auto-props=yes line must be before the [auto-props] line. This is really lame. It is a natural mistake to have enable-auto-props=yes after [auto-props]. Instead, auto-props should be enabled if [auto-props]] is uncommented.

To test this out, if you have read/write permission to the source.eecs.berkeley.edu SVN repositories, try:

Note that testfile.txt had $Id$ properly substituted. If it had only $Id$ and not $Id: testfile.txt 8 2009-03-05 01:27:44Z cxh $ then keywords were not being substituted and that ~/.subversion/config had a problem.

Checking Keyword Substitution

To check keyword substitution on a file:

See ptII/doc/coding/releasemgt.htm for information about how to use ptII/adm/bin/svnpropcheck.

Fixing Keyword Substitution

To set the keywords:

Keyword problem: one line in auto-props masks another

http://subversion.tigris.org/issues/show_bug.cgi?id=2036 describes a four year old bug where the ~/.subversion/config file has problems with lines masking each other. For example, if ~/.subversion/config has:

then if the user creates a makefile, it will have keywords set, but if the user creates a Makefile it will not have the keywords set. If course, this only matters on real file systems such as Mac OS X or Unix. Windows users have the oddly antiquated case insensitive, case preserving file system.

Problem creating two filenames that differ only in case

Under MacOS with svn-1.4.4:

However, the same command works under Solaris with svn-1.4.5

Problems with Eclipse and ssh

The problem was that if a user had an incorrect password, then the ssh server would block ssh connections:

netstat on source's console shows that soda1am.Equip has a bunch of TIME_WAIT connections on sshd. soda1am.Equip is the machine through which the connections from AirBears arrive.

Looking around on the net finds http://archive.netbsd.se/?ml=openssh-unix-dev&a=2007-10&t=5430083 which suggested editing /etc/ssh/sshd_config and changing MaxStartups.

However, the real question is: Why does this occur?

It turns out one of our Eclipse users was using either Subclipse or Subversive to connect via ssh. They had the wrong password, so there were many bogus connections.

The account that was causing the problem was using Eclipse on the Mac with these versions of Subversive: (:source) Subversive SVN Connectors 2.1.0 Subversive SVN Team Provider (Inclubation) 0.7.3 SVNKit 1.2.2 Implementation (Optional) 0.7.3 (:sourceend:)

I edited /etc/ssh/sshd_config:

Svnsync

We use svnsync on source to get a copy of the Kepler tree. The svnsync Unix user has a script called /export/home2/svn/synckepler

The script is run from a cron job every 10 minutes.

svnsync: Couldn't get lock on destination repos after 10 attempts

If svnsync fails with svnsync: Couldn't get lock on destination repos after 10 attempts, then run

See http://malsserver.blogspot.com/2008/12/failed-to-get-lock-on-destination-repos.html

Get repository folder children operation failed

After upgrading the svn server to 1.7.2 on source, Eclipse Indigo SR1 (M20110909-1335) with "SVNKit 1.3.5 Implementation (Optional) 2.2.2.I20110819-1700 org.polarion.eclipse.team.svn.connector.svnkit16.feature.group Polarion Software" was failing when the URL was svn+ssh://source.eecs.berkeley.edu/chess/ptII.

The problem is that clicking on trunk results in <An error occurred whil accessing the repository entry >. The stack trace is

svnserve Processes

It turns out that there were lots of svnserve processes on source.eecs.berkeley.edu. Details may be found at http://svn.haxx.se/tsvnusers/archive-2007-09/0056.shtml and http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407949

My solution was to write a script that killed those processes. However, this script was not super-reliable as it was still possible to run out of swap between times the script ran.

Unfortunately, this script is not super-reliable in that snv: connections will sometimes start to fail because rerunning S98svnserve fails.

The cause was Kepler users with IntelliJ were setting up svn in such a way that IntelliJ made many connections to the server.

Sean Riddle writes:

Sean also pointed out that http://youtrack.jetbrains.net/issue/IDEA-56714 describes the issue.

svn: This client is too old to work with working copy '.'; please get a newer Subversion client

If you use Subversion with Eclipse and install a Subversion plugin that is newer than the command line svn command, then when you run svn, you will get svn: This client is too old to work with working copy '.'; please get a newer Subversion client. The solution is to update the version of svn on your machine.

Subversion downloads may be found at http://subversion.tigris.org/project_packages.html

Mac svn details

I have an updated version of svn installed at /opt/subversion/bin/svn.

My ~/.MacOSX/environment.plist file includes that version in the path with:

You can edit environment.plist with either a text editor or with /Developer/Application/Utilities/Property List Editor.app

Mac: svn killed by signal 15

If running svn co fails on the Mac with Killed by signal 15, then edit ~/.subversion/config and set ssh to $SVN_SSH ssh -q

See http://tech.barwick.de/development/svn-subversion-fixing-killed-by-signal-15-error.html and http://subversion.tigris.org/issues/show_bug.cgi?id=2580

(Thanks to Gilles Lasnier)

Eclipse: svn: Compression of svndiff data failed

Eclipse was failing with:

It could be that SVNkit needs to be updated.

1. Go to the SVN Eclipse instructions at: http://www.eclipse.org/subversive/downloads.php
2. Get the Polarion update URL from http://www.polarion.com/products/svn/subversive/download.php?utm_source=eclipse.org&utm_medium=link&utm_campaign=subversive As of 9/10, for Helios, it was: http://community.polarion.com/projects/subversive/download/eclipse/2.0/helios-site/ Other versions of Eclipse should use the appropriate update site
3. In Eclipse, do Help | Update Software and then Add the http://community.polarion.com/projects/subversive/download/eclipse/2.0/helios-site/ URL
4. Select the SVNkit appropriate for your version of Java. To check your version of Java, run svn --version. See http://www.polarion.com/products/svn/subversive/connector_discovery.php?utm_source=eclipse.org&utm_medium=link&utm_campaign=subversive for details.
5. Complete the installation.

TortoiseSVN

Summary: Windows 7 users have problems with Tortoise SVN, try http://cvsgui.sourceforge.net/ WinCVS instead.

Details: In Windows 7, Microsoft changed how some registry entries are handled. TortoiseSVN was using these entries so that in the Windows Explorer file browser, users could right click on a file or directory and perform SVN operations. Apparently, there are a limited number of images that can be used. See http://stackoverflow.com/questions/1057734/tortoisesvn-icons-not-showing-up-under-windows-7

Merging Two SVN Repositories

Dump with:

I had to create trunk/ptpapers/ealpapers and commit it.

Then do the merge:

svn externals property: How to check out a repo within another repo

To get accessors to work, we need to do (:source:) cd $PTII/org/terraswarm/accessor svn co https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk/accessors

Summary: I did not find a way to do this. The workaround is to have configure check out the repo, which I will do now.

Details:

See https://www.terraswarm.org/accessors/wiki/Version0/Implement as to why we need to do this.

SVN supports externals. http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html states:

So, in theory, we could add a svn:externals property to the ptII svn repo.

However, there are at least two issues here:

1. If we set up the ptII repo so that it has the svn:external property set to check out https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk/accessors, then this will only work for someone who has access to that repo. It will not work for anonymous users who are checking out the ptII tree who do not have access to the accessor repo. If we tell anonymous users to use "svn co --ignore-externals https://repo.eecs.berkeley.edu/svn-anon/projects/eal/ptII/trunk ptII", then the svn command would work, though the accessors would not.
2. If we had the accessors repo anonymously readable, then we will have problems because the urls for the read/write and read only versions are different.

• https://repo.eecs.berkeley.edu/svn-anon/projects/terraswarm/accessors/trunk/accessors - anonymous access, if we enabled it
• https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk - read/write access

The property can have only one value.

The above is partly an artifact of repo.eecs, but it is a general problem. I don't think repo.eecs can be modified to better handle this.

One idea was to do something complex with HTTPS and redirects, but that is not likely to work. I tried it before and reviewing the web shows that it would work with the browser, but svn will want the user to run svn relocate.

Thus, in the near term, we should have $PTII/configure check out https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk/accessors.

In the longer term, we should make https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk/accessors publicly readable. Perhaps $PTII/configure could check out the proper URL.

Ideally, the code that requires that https://repo.eecs.berkeley.edu/svn/projects/terraswarm/accessors/trunk/accessors be checked out would have a good error message that would tell the user what to do.