SVN creating a new repository

Since I am now running my own SVN server there is only a slight cost in time to creating a new repository.  The top level directory in an SVN server is the repository and has to be created on the server rather than creating lower level directories which can be done by Tortoise SVN.  Getting round running at the adminstrator level is handy about svnSync and also about the SVN hosting services such as Codesion  and SlikSVN.

So on synology SVN host I logged in as root, there may be better ways of doing this but this worked for me.  Created my new site:

svnadmin create /volume1/svn/new_repository

This now inherits the wrong file permissions (root) so the directory listing looks like this:

so I moved to the directory and changed the owner and group:

cd /volume1/svn/new_repository
chown –R svnowner:users .

(don’t forget the trailing dot) and now it looks like this:

Next you need to add your username and password to the configuration file new_repository/conf/passwd (I am using vi for the editor) eg

Then in the same directory you need to change the following entries for the configuration file (svnserve.conf)

Make anonymous access have no access and authorised access write access:

Turn on using the local password database:

I also changed the realm to my URL but that is optional.

Now you can import your new directory using the method I talked about a while back.

Installing Python Pyjamas and Pyjamas desktop for Windows 7

I am testing out python pyjamas as a gui front end which I can scale from a desktop app to web app to cloud deployable scalable app with very little change.  I have tried a number of different GUI stacks, the last was pytgtk which only worked with 32 bit Python which I had to install on top of my 64 bit python.  To start I have gone back to 64 bit python.

Going to the pyjamas wiki getting started  I started using the windows help.  I noticed it was a little out of date so decided to write my experience here.  I have already got a working version of Python 2.72 64 bit on Windows.

Next I installed tortoiseGIT as I have used TortoiseSVN a lot.  I also needed to install the Windows GIT client which I should have done first.  Then I create a pyjamas directory in my download directory and use right click Git clone to create the directory.

You need to change the URL to git://pyjs.org/git/pyjamas.git and press OK.

The first time I did it it failed so I deleted everything and tried again and this time it worked.

I then installed comtypes which was version 0.6.2.  I had two versions of Python installed so I selected Python 2.7.  It then had an error at then end:

Carrying on, assuming that GTK may not be needed as Pyjamas desktop is using MSHTML and for my desktop I am at the moment only worried about desktop Windows apps. (I really don’t want to go back to Python 32bit again) I copied the pyjamas directory to my C drive so that I had the following directory C:\pyjamas\pyjd

I updated the system path  ControlPanel->System->Advanced system settings->(Advanced Tab)Environment Variables->Edit path  I added C:\python27;C:\pyjamas\bin. Note the pyjamas bin directory is added in the next step:

Open up a command window and then run which will create the bin directory:

cd \pyjamas
python bootstrap.py

I then created a build.bat in the helloworld directory:

pyjsbuild.bat --print-statements Hello

and also a run file:

pyjd Hello.py

Pyjamas works by combining files from the public directory eg files and template html and your code.  In order to use either the output or the desktop you must run the build process first.  Then you can use the run file first the app just opened up  in a new window and worked:

If I opened the browser with output\hello.html I just got the static text but need to change to the output directory and run the html file (so the default location of other files works) then I get the application in a browser window.  I was using by default IE and didn’t work on getting the others to work.  This from start to end took me about 3 hours including writing my notes as I went.

SVN sync

SVN has a very nice sync feature.  I have used at the end of a project to hand over by coping the version control information to a client repository.

I normally use TortoiseSVN and AnkhSVN to access the SVN repository but for this you you need an SVN client.  I used the the SlikSVN client with the typical configuration since they are selling hosting they are likely to make sure it works well (I used CVSDude way back now its unclear if it is called Codesion or Collabnet).  This has the svnsync command in it.

I got started with a post by Paul Querna.  Since I was doing it on a Windows machine and had a couple of problems I have written about my experience here.

Instead of defining environment variables I just created a number of batch files.   The first to make sure my SVN environment is working:

"C:\Program Files\SLIKSVN\bin\svn" --version

This command should return the version and a whole lot more info.  Then I tested access to the destination and source repositories eg:

"C:\Program Files\SLIKSVN\bin\svn" list https://myAcct.svn.cvsdude.com/myProj –username secretUser --password

secretPW

or

"C:\Program Files\SLIKSVN\bin\svn" list svn://192.168.0.0.1/myProj –-username secretUser -–password secretPW

This will return nothing for the destination repository as nothing in it and the  list of directories in the source repository.  If the hook properties need to be changed then the following code should be executed in the root directory of the source repository:

$ echo "#!/bin/sh" > hooks/pre-revprop-change

$ chmod 755 hooks/pre-revprop-change

Now you are ready to initialise syncserve:

"C:\Program Files\SLIKSVN\bin\svnsync" init svn://192.168.0.1/myProj --sync-username desSecretUser --sync-password destSecretPassword https://myAcct.svn.cvsdude.com/myProj --source-username sourceSecretUser --source-password sourceSecretPassword --non-interactive

You may get a warning about no supporting atomic revision and upgrading to 1.7.  For 1.6 this was fine.

svnsync: warning: W200007: Target server does not support atomic revision property edits; consider upgrading it to 1.7 or using an external locking program
Copied properties for revision 0.

And now you should be ready to start the sync (just change init to sync):

"C:\Program Files\SLIKSVN\bin\svnsync" sync svn://192.168.0.1/myProj --sync-username desSecretUser --sync-password destSecretPassword https://myAcct.svn.cvsdude.com/myProj --source-username sourceSecretUser --source-password sourceSecretPassword --non-interactive

You will then get a list of changes copied over (the . after Transmitted file data refer to the amount of data transferred):

Copied properties for revision 9.

Transmitting file data …..

Commited revision 9.

Mathematica Debugger Traps

When I first started using WorkBench 2.0 and Mathematica 7.0.1 I found the operation of the debugger flaky.  However I have identified a number of issues have helped me.

1 My problem was due to using a global connection in the module:

conn=OpenSQLConnection[…

This then prevents the debugger working.  I have now reworked my code so that I don’t use this type of connection. 

I have tested whether it is expensive to open a SQL connection on every call or if you do it just once for a group of calls.  Doing 10 simple queries took 1.7 seconds if the connection was opend and closed every time and ca 1 second if it was only opened once.  So for the generation of reports I am going to avoid the considerable work involved in doing two headers and wait until I can generate them automatically.

2 Timing.  You have to wait until the Workbench has finished loading.  This takes a number of seconds and you can easily start executing code in the opened notebook first.  If you do that the bottom right of the workbench screen will look like this:

The input number will be 2 rather 7 or 8 which is normal if the debugger is going to work.

3 I tried SVN addin to the workbench and that was a bad idea.  I had to uninstall and reinstall workbench to get back a working version.  I saw a post where Wolfram are working on the SVN version so I hope that comes through.

4 In the debug screen I make sure I delete other debug activities before starting a new debugging session.

5 Be good about default directories.  I tried a different directory for the module and the debugger wouldn’t breakpoint at it.  Moving it to the normal directory worked fine.

Starting a TortoiseSVN project

SVN is a great version control system and TortoiseSVN a great tool to access it.  I currently run the SVN server on a Windows desktop running as a serivce and each night back taking a rolling backup of it.

However I find one thing slightly confusing and that is how to move an existing project into SVN.  Typically you start something off and then decide it is worth a little more effort so add it to version control.  However the Tortoise SVN import tool is annoying in that when you import a folder it does not become the working copy.  So the help manual recommends you use Section 4.2.2, “Import in Place”.  This is then copied from the manual with some extra graphics:

1. Use the repository browser to create a new project folder directly in the repository. (right click in File Explorer to get pp up menu then choose TortoiseSVN->Repo-Browser

2. Checkout the new folder over the top of the folder you want to import. You will get a warning that the local folder is not empty. Now you have a versioned top level folder with unversioned content. (Make sure the URL of the repository contains the sub directory you have just added):

3. Use TortoiseSVN → Add... on this versioned folder to add some or all of the content. You can add and remove files, set svn:ignore properties on folders and make any other changes you need to.

4. Commit the top level folder, and you have a new versioned tree, and a local working copy, created from your existing folder.

This is actually very easy but I remember getting confused before.