A byte stream of thoughts.
Apparently it was a while ago since I had troubles with infrastructure :), but this time it took too long to leave it unnoticed. Quite some time ago I have created several files in the subversion repository with the ‘|’ character in them, which gave problems checking them out on a Windows… ehm… box (if you can call Surface a box :)).
Continue reading “Manipulating files with @ sign in a subversion repository”
Ok, I really need to document this for future. This costs waaaay too much time even having clues from all kinds of places.
Anyway, I was busy making a simple script to update a site remotely by triggering an svn checkout. Easy thing except for that the connection to repository is done using HTTPS and guess what – the certificate needs to be accepted. Trying things like ‘–trust-server-cert’ (needed to upgrade to svn 1.6.x for trying this out, on Ubuntu point to the Lucid repository if anyone needs it) didn’t help. Then I played ‘smart’ and logged in under the Apache user and tried to do the same trick manually. I’ve got to the point of accepting the certificate, etc, but… next time the same story.
Well, what ought to happen was that the user home folder (/var/www in my case) was NOT owned by the Apache user, but by the root. Damn… all the certificate acceptance stuff simply went nowhere, but I didn’t get a single warning on that!
So the solution was simple – make /var/www owned by the actual Apache user (www-data in my case under Ubuntu), log in under this user (sudo so www-data) and perform the operations I needed with the svn repository manually ONCE not forgetting to accept the certificates PERMANENTLY of course. Since then everything works fine.
Life goes by…
Since installing subclipse I’ve got same problem I’ve already had on MacOSX when my subversion command line client (1.5.x) started to complain that the repository was already used with a newer version. Downgrading repository version works, but not a very nice solution, so I have decided to get the latest version. Apparently this is not just an aptitude command, but a little more. This is what have worked for me finally:
Download the source code for 1.6.3 (or later when it becomes available) and the corresponding dependencies from http://subversion.tigris.org. You have to have the following files in the case of 1.6.3:
Download the OpenSSL from http://openssl.org/source/ if you need https support:
Then perform the following commands:
sudo apt-get install libssl-dev
sudo apt-get install zlib1g-dev
tar xvfz subversion-1.6.3.tar.gz
tar xvfz subversion-deps-1.6.3.tar.gz
tar xvfz openssl-0.9.8k.tar.gz
cd openssl-0.9.8k
./config
make
cd ../subversion-1.6.3
./configure --with-openssl=/usr/local/ssl --with-ssl --with-zlib=/usr/include --without-berkley-db
make
sudo make install
Having all this I’ve got working subversion (client) 1.6.3 under Ubuntu 9.02 .
TIP: If you done all above and typing svn --version still shows the default 1.5.x try another console. The installation of subversion apparently adds a new path which not picked up on the fly.
I have a habit of reviewing my changes before committing them to the repository. What suprises me is that so far I have only seen home-brewed scripts to perform a ‘batch’ review of all changed files. But ok, how difficult is that? So for my current project I came up with a similar solution. Here are some lines of bash script:
#!/bin/sh
# Find the list of changed files.
FILES=`/usr/local/bin/svn st | grep ^M | /usr/bin/sed ‘s/^M[ ]*\(.*\)/\1/’`
for FILE in $FILES; do
# Invoke favorite diff viewer to see the changes.
svn diff –diff-cmd /Users/oleksii/Scripts/diffwrap.sh $FILE
done
It could have been beautified a bit, but what a heck… BTW, the ‘magic’ diffwrap.sh’ looks like the following for me (use any other diff tool if you like, I just happen to use DiffMerge because it is available for all the platforms I am using now):
#!/bin/sh
DIFF=/Applications/DiffMerge.app/Contents/MacOS/DiffMerge
LEFT=${6}
RIGHT=${7}
$DIFF $LEFT $RIGHT
It should not be difficult to see which OS I am using here :).