Operating System - OpenVMS
1748218 Members
4336 Online
108759 Solutions
New Discussion юеВ

Re: Subversion Client for OpenVMS

 
SOLVED
Go to solution
Steven Schweda
Honored Contributor

Re: Subversion Client for OpenVMS

> if it's sending you a set of differences [...]

It may be _storing_ a set of differences, but
I'd expect it to be sending you a
reconstructed file, with all the bytes
reconstructed properly. Assuming that the
critical file attributes do not change, or
that the changes are also maintained, what
could go wrong?

> I think it would be pretty tough to know
> when the VFC bytes are control bytes and
> when they are just data.

No, it's easy. The first two bytes are the
first byte count. After that, just count the
bytes to find the next byte count. And so
on. (It might be hard if you didn't start at
the beginning, so don't do that.)

> Which is why I'm hoping you'll do the port
> so I won't have to :-).

It might be more educational for you. And
I'm currently engaged in a tedious effort to
push some VMS changes into the next cdrtools
(cdrecord and friends) release.
Craig A Berry
Honored Contributor
Solution

Re: Subversion Client for OpenVMS

>It may be _storing_ a set of differences, but
>I'd expect it to be sending you a
>reconstructed file, with all the bytes
>reconstructed properly.

Subversion does not conform to that expectation. It sends differences in both directions over the network.

>> I think it would be pretty tough to know
>> when the VFC bytes are control bytes and
>> when they are just data.

>No, it's easy. The first two bytes are the
>first byte count. After that, just count the
>bytes to find the next byte count. And so
>on. (It might be hard if you didn't start at
>the beginning, so don't do that.)

I have not yet looked into the details of what Subversion sends across the network, but more than likely you get a byte offset and a chunk of data. If the byte offset puts you in the middle of a record in a record-oriented file with variable-length records, things could get interesting.
Steven Schweda
Honored Contributor

Re: Subversion Client for OpenVMS

> Subversion does not conform to that
> expectation. [...]

None of that matters. Any file on VMS
comprises a stream of bytes, and meta-data
which explain how to interpert those bytes.

Any system which can correctly reproduce the
byte stream and the meta-data can do the job.

I don't know if Subversion can be persuaded
to do the job without adding features, but
the way that the VMS file system interprets
the byte stream is of no consequence to the
actual byte stream. Bytes are bytes. Look
again at that DUMP output. One byte looks
about the same as the next one. Records (and
their byte counts) exist only in your
interpretation on those bytes, not in the
bytes themselves.
Patrick Traill
New Member

Re: Subversion Client for OpenVMS

I admit I had not been thinking about VFC or for that matter indexed-sequential files. I was principally concerned with storing platform-independent source-code.

In general, how VMS files should be represented in depends on what you want to do with them, and especially on whether you want to use them on non-VMS platforms.

One needs to remember that a VMS file (as presented by RMS) is conceptually a stream of records, with optional redundant(?) indices. There are at least three views of a VMS file: programmatic, presentation and storage.

1) The view an application programme has of a file (as presented by RMS or some programming language) is a stream of records. These may be of fixed or variable length and contain formatting (VFC) information, which is not regarded as part of the application data (anything else?). There may also be the ability to retrieve records based on content, using indices maintained by RMS, which may be reconstructed from the record stream and index specifications. The record stream view is sufficient(?) to reconstruct the entire file, provided we include the file header information and index specifications.

2) The view a user has of a readable file presented by commands such as TYPE is of a stream of bytes. This is not in general sufficient to reconstruct the record stream, since any byte used as a delimiter could equally well occur in a record.

3) The view that the RMS routines have of a file is of the raw data as stored in the On-Disk Structure via the QIO interface to the ACP. This may be regarded as a random access array of bytes or bits or indeed as a stream of bytes.

To store a file in Subversion, it must be represented as a byte stream, which is trivial for the presentation and storage view. In both these cases, the only Subversion attributes required would be for the file-header information. For the record-stream view, however, one needs to add record lengths and formatting information to the byte stream. The most flexible format would be a variable-length record header. One would also need to add the index specifications to the Subversion attributes.

For many text files, especially programme source, the presentation view will be adequate, and the ambiguity about the record stream acceptable. Such files are also easily processed on other platforms.

To process a record stream on a non-VMS platform would need special purpose software. Although not terribly complicated, it would have to be supplied specially.

To process the raw view of a sequential or direct-access file is also manageable, but it is forbiddingly complicated for indexed-sequential files, even leaving aside possible versioning issues.

On the other hand, storing the record stream of an indexed file makes reconstructing it much costlier, as the indices need reconstructing.
Selden Ball
Advisor

Re: Subversion Client for OpenVMS

Falk,

Like others, I'm very interested in a subversion client for OpenVMS, in our case on an Alpha running OpenVMS v7.2-3.

Have you had any luck building it?
Mats Backlund
New Member

Re: Subversion Client for OpenVMS

Hi,

I have tried the Java variant of subversion called SVNKit on OpenVMS which seems to be an easier way to go rather than trying to compile a native subversion client. I have JDK 1.4.2-4 installed on the VMS and downloaded the org.tmatesoft.svn_1.1.0.standalone.zip file found on http://svnkit.com/download/index.php
The biggest challenge with the SVNKit is to set all logicals for Java so that UNIX-style filenames and similar things work correctly when running SVNKit on OpenVMS. I have succeeded to add files to a repository on Windows and also updated my working folder on VMS from Windows. The command line syntax for SVNKit is the same as when running the standard command line client (svn up, svn co http://xxxx, svn cleanup, etc).
Ian Miller.
Honored Contributor

Re: Subversion Client for OpenVMS

If you could write some notes on what you did I think serveral people would be interested in how you got it to work.
____________________
Purely Personal Opinion
Patrick Traill
New Member

Re: Subversion Client for OpenVMS

Dear Mats,

This sounds encouraging.

If you manage to write it up as requested, could you perhaps also mention what view of the VMS file system it gives you.

I presume it will be suitable for source code, but clarity on this point would be useful.
(See my reply of Oct 9, 2006 09:50:46 GMT for come of the issues).
ptrskg
Frequent Advisor

Re: Subversion Client for OpenVMS

Hi Falk and others,

I have during the week worked with SNVKit, a Java implemetation of the SVN client, on OpenVMS with some success and also sent patches to TMate software that hopefully will be included in the next version of this package. (http://svnkit.com)

I haven't tested everything but I have it working with remote servers, svn- and http-protocol, and also with a local repository. When I tried https it failed and I think it is related to Java/VMS stuff.
I am running 8.2-1 on an Integrity with Java 5.0-1 and will soon try it on my Alpha.

I think this can be something to use and as soon as we have a stable environment we will move our code from CVS to Subversion. The server will be on Linux...

Peter
Heinz Huber
New Member

Re: Subversion Client for OpenVMS

Using SVNKit:
What logicals did you set?
I'm having problems with filenames containing more than one dot (.). All dots except the last one are converted to underscores (_).

My current settings (worked for CVS):
$ set proc/parse=extended
$ define/job decc$efs_charset enable
$ define/job decc$efs_case_preserve enable