Subversion on RISC OS

Hi all.

I’ve noticed that the Subversion command-line client has been ported to RISC OS, which is great.

We’re using Subversion at work, and on Windows, there’s a GUI client called TortoiseSVN that integrates with Explorer, letting you perform Subversion operations just by right-clicking on a file or directory and choosing a command.

I’ve found that very useful, and it also works great together with the WinMerge diff viewer.

I’m wondering about making something like TortoiseSVN in RISC OS, as well, perhaps in some way integrating with the Filer, so I was wondering if anybody else might be interested in that, too, and if someone knows about any other projects for this?

Regards,

Terje

I would be interested, I use the subversion client on RISC OS and have used Tortoise SVN on Windows and would love to have an equivalent GUI on RISC OS.

Though I am wondering if I should be moving to Git (as it seems to be becoming increasingly popular), although I can’t at the moment as there isn’t a RISC OS client.

Regards,
Alan

Hi Alan and thanks for your reply.

I’ve just ordered an AMRiniX (having used BeagleBoard up to now), and having been away from RISC OS for a couple of years, I’m reading up on RISC OS programming again.

I used Subversion/TortoiseSVN on Windows, and VirtualAcorn, when working on a C++ version of the SpriteUtils module (https://www.riscosopen.org/forum/forums/5/topics/731), and I’d like to continue the work on that on real ARM hardware (the mentioned ARMiniX), also in order to ensure it works on modern ARM-based computers.

I’ve always admired TortoiseSVN’s interface, though I can’t claim to have used it very extensively – just while working on GeSHi a little. I would certainly love to see some form of SVN GUI for RISC OS, but like Alan, I would perhaps more like to see a port of a git client.

I would also be very pleased to see your C++ SpriteUtils module come to something, Terje. I followed that thread with interest at the time. Good luck!

I have been using the command line SVN on RISC OS for a while now, accessed by a range of taskobey files, which I generate automatically for each project. Some sort of GUI would probably be very useful.

Hi WFB and thanks. :)

Yes, I’m looking forward to get back to the project of reimplementing RISC OS using a high-level language.

When it comes to SpriteUtils, as I remember, it had performance comparable to the original version, when using some assembly code at strategic places (like inner loop pixel plotting). Without it, it was much slower.

I have a passion for ARM, RISC OS, C++ and computer graphics, and projects like this lets me get immersed in all of those areas. :)

Once we have a high-level language codebase, it becomes much easier to change and improve the system, compared to using assembly code.

Interestingly, when I started with Acorn Archimedes (in late 80’s), I thought it was great that the OS was implemented in assembly code, because it made it very fast. :)

I was even somewhat disappointed that they had made some of the components using C, rather than assembly code. :)

Nowadays, I think it’s more important to optimise programmer time than processor time.

Moreover, compilers are much better, so a compiler may match or exceed an assembler programmer when it comes to the perfrmance of produced code, simply because it may be able to take a larger context into consideration when optimising.

I did some preliminary porting of git, which compiled and ran but it fell over in filename translation and I had no further time to explore. I checked in the work so far into the GCCSDK autobuilder SVN. If anyone has more time to look at this I’d be happy to help them get up to speed…

I think git is quite key because it enables much better collaborative development than SVN does (see also github), and it’s really easy to put even tiny projects into git – no messing about with servers or repositories required, just type ‘git init’ in your working directory. Comes in handy for other things too – just imagine if you had !Boot in version control and could easily rollback changes, see what changed, etc.

Indeed, a port of git would be great. We have switched from CVS to git at work, and it really has too many advantages to list. It scales nicely from “my private repository” to “multi-million-loc project with hundreds of developers”. Although sometimes a bit to cli-y and Linux-y(the available GUIs are often questionable, no matter if the included git-gui or Eclipse with EGit or Atlassian SourceTree), I am quite confident that it is the free (D)VCS for the forseeable future.