Subversion (SVN) client for RISC OS

Am I missing a trick here or is RISC OS missing an up to date SVN client? The most recent one I’m aware of is dated 2012 and cannot connect to the newer database format.

I’m not sure about various database formats, but I was using a RISC OS client to connect to VisualSVN 3.x on Windows. I now use it to connect to a Synology NAS, running the latest Subversion server available for it.

I don’t remember where I got it from, and I had to run PatchSWP on it. If I remember, I’ll upload it somewhere.

Edit: Turns out I’d already done so! It’s here.

riscos.info is hosting 1.6.17… Which I now have a copy of… Working out how best to design a simple GUI app that uses the CLI to pull/push…

Right those of you who are following on chatcube will know I’ve settled on a window layout similar to SVN Workbench… I’ve also had the idea of including a BASIC tokeniser / detokeniser that automatically detokenises BASIC before pushing up therefore allowing proper diffs to be maintained on BASIC files. Of course it would be able to reverse the process when going the other way.

Any further suggestions would be welcomed.

I’ve also had the idea of including a BASIC tokeniser / detokeniser that automatically detokenises BASIC before pushing up therefore allowing proper diffs to be maintained on BASIC files.

How would this cope with files which don’t tokenise and detokenise symmetrically?

I’ve also had the idea of including a BASIC tokeniser / detokeniser that automatically detokenises BASIC before pushing up therefore allowing proper diffs to be maintained on BASIC files.

Harriet Baxeley’s Sidediff already does diffs on BASIC files. It might be worth investigating either making use of it, or seeing whether Harriet would share the code already written.

Proceeding with wrapping my GUI around the svn command-line v1.6.17. Hitting some problems when specifying a directory to checkout into…

Issuing the command…

*svn checkout svn://(ip address)/repos/brix SCSI::HardDisc4.$.brix_test

Gives me the error…
svn: Can’t create directory ‘SCSI::HardDisc4.$.brix_test/.svn’: No such file or directory

However, If I don’t specify a destination, it works as expected… Does anyone out there know what I’m doing wrong… According to the command syntax, I should be able to specify where to create the working copy.

I’ve had this before and so had to change directory to the absolute (parent) path and create the named working copy there.

*svn checkout svn://(ip address)/repos/brix SCSI::HardDisc4.$.brix_test

Looks like it’s not recognising that it’s a RISC OS path due to the ‘/.svn’.

If you use svn checkout svn://(ip address)/repos/brix /SCSI::HardDisc4.$/brix_test it should then work.

OK… Thanks… Got it working…

OK… Coming across another issue, which I think may be related to the previous one. svn command line client creates “c.file” on RISC OS, but on an RPi4 running Buster and pulling from the same repo using SVN Workbench I get “file.c”. AKA 8.3… This also happens with all the .h files…

Of course, under RISC OS when I call svn with info to get the last changed revision, I keep getting directory “c” not version controlled.

So it seems like an interesting example of failed filespec munging going on inside the CLI back-end… Either that, or there’s something I’m not getting here.

Of course, under RISC OS when I call svn with info to get the last changed revision, I keep getting directory “c” not version controlled.

I think that’s how it’s supposed to work. The ‘c’ is part of the file name and not a version-ed folder.

“I think that’s how it’s supposed to work. The ‘c’ is part of the file name and not a version-ed folder.”

Then why the discrepancy between what svn writes as the local working copy and what it keeps as it’s state database? Surely, if that’s the case, then svn info should be able to pick it up and munge it back.

OK… I’ve written a routine that under certain conditions will add the correct extension (the name of the errant directory) and move them up one level then remove the errant directory. This seems to work a treat, of course now the local file system is in sync with the svn internal cache.

The exact logic for this goes…
IF entry is “not a versioned resource” AND entry is a directory AND name length is <= 3 THEN munge it out as described above…

If anyone out there can think of any scenarios where this would fall over, then please let me know here.

Can the current maintainer of the command line svn on RISC OS please contact me regards a potential bug with the checkin command provided by svn. I can provide code that replicates this issue as required…

I think I was the one that updated the svn client to the then-current version. I wouldn’t call myself the maintainer though. Having said that, I have actually been working in updating the current patches so it works on a later version (I thought it was the current version as that was the version the autobuilder was downloading, but I found out that it was a somewhat older version. I’m not close to my computer equipment right now so I can’t easily check. I think it may have been 1.14 but I’m guessing.

I got as far as getting it to compiling but it didn’t link. I didn’t really know how to fix that as I’m not very routined at porting. Anyway, I focussed on other things but I did get an idea how to maybe find out the problem but I’ve not prioritised looking further into this.

Anyway, nothing concrete here, but since there’s talk about it I thought I’d let you know…

I’m currently using 1.6.17dfsg-1 to develop a GUI (WimpSVN) along the lines of SVN Workbench and have come across an issue with checkin. I can provide you with an archive of the current version of WimpSVN to demonstrate the hang-up I’m having with checkin functionality. Come back to me here if you’re interested.

Right… With suggestions from David Higton, I think I understand a bit more about my checkin woes.

The command below seems to fail because of the “.” between SCSI::HardDisc4 and the root “$” symbol…

svn commit SCSI::HardDisc4.$/Development/Projects/WimpSVN/SVNTest/Repository/ —file MEM::0.$/X!WimpSVN/Tmp/bcxojqxa { > MEM::0.$.X!WimpSVN.Tmp.ccikwubj }"

However… If I set the CSD to SCSI::HardDisc4.$ and omit “SCSI::HardDisc4.$/” from the first parameter, it works as you’d expect.

So it appears to be a RISC OS filespec translation issue inside svn for that particular command. All other commands that I’ve already implemented take their paths in the form above and function correctly.

Implemented commands being…
add, delete, checkout, revert, info, status & update.

Anyhow… That’s where I am for now…

I’ve run into that one myself. As a workaround I tend to set the CSD to wherever my code is, and then call SVN without a path at all. Obviously that’s a bit tricky when you’re ‘wrapping’ it with a GUI!

svn commit SCSI::HardDisc4.$/Development/Projects/WimpSVN/SVNTest/Repository/ —file MEM::0.$/X!WimpSVN/Tmp/bcxojqxa { > MEM::0.$.X!WimpSVN.Tmp.ccikwubj }"

I think the correct way of dealing with this is to make sure that any absolute RISC OS path that gets converted to Unix form has a leading ‘/’, so that any unixy code which looks at it will treat it as an absolute path instead of a relative one. I.e. try this:

svn commit /SCSI::HardDisc4.$/Development/Projects/WimpSVN/SVNTest/Repository/ —file /MEM::0.$/X!WimpSVN/Tmp/bcxojqxa { > MEM::0.$.X!WimpSVN.Tmp.ccikwubj }"

Ok… Should be a fairly easy change… All the file spec munging goes through a single FN. Will give that a whirl today and get back here with further developments…

After 10 years or so, I’ve been attempting to resurrect some old RISC OS projects. Since I now use SSH to access SVN, I was hopeful when I noticed in the !SVN change log, that it supports svn+ssh. I can’t seem to get this to work however:

*svn ls svn+ssh://svnsvn.lan/riscos-projects/avalanche/trunk
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: Can't read from connection: RISC OS error (0xde Handle is either illegal or has been closed)

*ssh svn@svn.lan

Apologies for the formatting, the forum keeps trying to turn the SVN URL user-at-host into a mailto link and I don’t know how to stop it.

OK… Haven’t had a chance to test it to breaking point, or with multiple files / selections, but it seems that by prefixing the path with a leading “/” as Jeffrey Lee suggests, I CAN upload a test file I added to the RISC OS end using the WimpSVN GUI. Window refresh post commit is bugged and doesn’t yet reflect the change. (Local copy needs to be re-scanned after reloading WimpSVN…) But a step further forward…

I finally got to look into Subversion again, and I managed to compile version 1.10.4 which is a whole lot newer than the 1.6 we currently have.

However, it unfortunately doesn’t seem to work. From version 1.7 and later subversion uses sqlite to store metadata. Unfortunately this doesn’t seem to work. I’m not sure how to approach fixing this either so unless somebody has a good idea I suppose this project ends here.

This means checking out fails with an error something like this:

svn: E200030: sqlite[S26]: file is not a database, executing statement ‘CREATE TABLE REPOSITORY blah blah lot’s of SQL … ’

Should anybody want to play with it (but according to the above, I suppose you won’t get far…) you can download the riscpkg package from here

Disappointed by the results of all this work… :(

Jan-Jaap. You’ve obviously done a fair bit to the code to get as far as you did… Two things…

1> Would replacing the sqlite metadata code with the format we had working in 1.6 break compatibility with what’s out there? If not, the obvious answer to me would be to back-port the equivalent code in 1.6 to the RISC OS port of 1.10.4. Especially if it’s all about the working copy metadata rather than the repo database. Saying that, I haven’t seen how the source is written, so this could be impractical.

2> This is more for my project, but is there an easy way to dump out all the hex error codes that are possible to produce and see from the output. It would be interesting to have a list of these and their meanings for WimpSVN. Yes I’ve tried examining the source in this respect, but everything I see is in offset + base notation and I can’t see any definition of what each of the “bases” are… I’m thinking along the lines of… “If I can search the buffered output for these hex codes, then this might be more accurate than looking at message strings (which might change slightly across versions).”