Subversion Client for OpenVMS

[falk wiegand]

We tried to compile the Subversion client on OpenVMS but we failed because the Apache runtime library is not available on OpenVSM. Is'nt it? Or does anyone compiled it successfully? My customer wants to use Subversion because it's sources are so different types and the OpenVMS sources are about 25% of the overall projects that the major part is out of OpenVMS but an essential part of it.

[Jan van den Ende]

Falk,

Apache on VMS is a layered product.
Instal SWS (the VMS port of Apache) from the freeware CD or the HP VMS website, and you should be home.

PS What is your VMS version? For older versions there is no SWS, but you should be able to get OSU or WASD.

hth

Proost.

Have one on me.

jpe

[Jansen_8]

You probably also need the sources (at least for the .h files) You can download them from HP.

Jouk

P.S. I'm very interested in a SVN client for VMS myself. Porting it is on my wish-list.

[Richard Brodie_1]

Jan,

The Apache portable runtime is an OS
abstraction layer developed by the Apache web server project (covering things like memory allocation, threading etc.). It is only loosely related to Apache itself; and an alternative web server, not at all. Subversion is a CVS (or CMS) like source code management system.

I seem to recall a kit around for Apache 1.0 but that would be too low an APR version. Digging the current one out of the Apache sources and getting it to build sounds like a largeish project. Having a properly kitted APR library would be useful; in the meantime, I think the practical thing to do would be to do something like put the working copy on some flavour of Unix and NFS mount it on VMS.

[Craig A Berry]

FWIW, the Apache for VMS sources can be downloaded at:

http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html

The APR must be in there somewhere. Whether Subversion would exercise all the same bits as Apache I don't know.

I've often thought a Subversion client would be a nice thing to have on VMS. A first cut would probably have to assume stream files. Even nicer would be a way to store RMS attributes as metadata so you could deposit any type of VMS file. All of this probably requires real work.

[Patrick Traill]

Here is another user very interested in a Subversion client.
It could be so much more reliable and efficient than what we now do with FTP.

On the other hand, an advantage of going via a PC is having Tortoise to check the Commit.

I recently ported a pair of CMS libraries (including history and classes) to Subversion,
and considered trying the apache port,
but eventually decided to write a client on VMS to push the stuff via a server on a PC into Subversion.

The RMS attributes should be easy enough to encode with Subversion attributes.
These should be symbolic (no numeric codes) as in Set File /Attributes,
and in a namespace such as "svn-vms:".

Who knows which version of the APR Subversion requires, and what has currently been ported?

[labadie_1]

Hello

Have you thought about using something else than subversion ?

Thierry Uso has ported Superversion to Vms
http://perso.orange.fr/thierry.uso/suv.html#suv-descriptif

Hope that helps.

Gerard

[Craig A Berry]

Patrick Traill said:

=======
The RMS attributes should be easy enough to encode with Subversion attributes.
These should be symbolic (no numeric codes) as in Set File /Attributes,
and in a namespace such as "svn-vms:".

Who knows which version of the APR Subversion requires, and what has currently been ported?
========

It would not just be a matter of encoding the attributes from the file header. For example, with a VFC file, you need another 2-byte "header" for each record in the file. Even if you successfully read in and store the control bytes when checking something in, you would need a way to recognize record boundaries when checking it back out. No doubt this type of problem has been solved many times before, such as in the STRUVMS support in the Process Software FTP utilities. But as I said before, it would be real work to implement this in Subversion, though well worth doing if someone has the time.

What's been ported would be whatever version of the APR is in Apache 2.0.

[Steven Schweda]

> It would not just be a matter of encoding
> the attributes from the file header.

Yes, it would.

> For example, with a VFC file, you need
> another 2-byte "header" for each record in
> the file. [...]

No, those bytes are in the data in the file.
They only need to be interpreted properly,
which will be done if the file attributes are
restored along with the data.

To see the "record boundaries" yourself,
compare the output from "DUMP /RECORDS" with
that from plain "DUMP" on a suitable file.
The only requirement is that the raw file
data be stored and retrieved, rather than
letting anyone try to interpret the records.

> No doubt this type of problem has been
> solved many times before, [...]

Info-ZIP Zip and UnZip, for example.

[Craig A Berry]

Well, maybe, Steven. But if it's sending you a set of differences rather than an entire file, I think it would be pretty tough to know when the VFC bytes are control bytes and when they are just data. Which is why I'm hoping you'll do the port so I won't have to :-).