Subversion Client for OpenVMS

[Larry Bohan]

just to throw this out there, a very small, bare-minimum,
working example from Alpha VMS 8.3 (all patches/eco's, ods5 working device),
using Java 1.5.0 against a linux SVN server.

Caveat: i haven't tried much more than 'svn list' so far.

I started getting SVNkit going under a GNV (2.1-2) bash shell,
then worked my way back to getting SVNkit working from
a simple VMS (dcl) login.

I haven't worked with Java very much on VMS, or elsewhere.

I was able to get this minimal example to fly, with almost
no special JAVA$ logicals. in the real world, I'd expect
that wouldn't be the case. especially wrt. adds/commits
and/or various merges/diffs.


$ @jsvn2.com "ls" "svn://someserver/someproject/branches/qa/"
Authentication realm: <> AcmeCorp
Username:
Password for '':
v00_003_0006/
v00_003_006/
v01_000_0013/
v01_000_0014/
v01_000_0015/

$ sh log/job decc$*

(LNM$JOB_864A5140)

"DECC$ARGV_PARSE_STYLE" = "ENABLE"
"DECC$EFS_CASE_PRESERVE" = "ENABLE"
"DECC$EFS_CHARSET" = "ENABLE"
"DECC$PIPE_BUFFER_SIZE" = "32767" ! NEEDED?
"DECC$POSIX_SEEK_STREAM_FILE" = "ENABLE"

$ pipe sh log/job java$* | sear/mat=nor sys$pipe sys$comm

(LNM$JOB_864A5140)

"JAVA$FILENAME_CONTROLS" = "-1"

$ sh proc/all
...etc...
Parse Style: Extended
Case Lookup: Blind
...etc...

$ type jsvn2.com

$ set noon
$ CP = "/toolsdisk/svnkit-1_1_6_3855/svnkit.jar"
$ CP = CP + ":/toolsdisk/svnkit-1_1_6_3855/svnkit-cli.jar"
$ CP = CP + ":/toolsdisk/svnkit-1_1_6_3855/trilead.jar"
$ CP = CP + ":/toolsdisk/svnkit-1_1_6_3855/jna.jar:."
$ OPT = "-Djava.util.logging.config.file=/toolsdisk/svnkit-1_1_6_3855/logging.properties"
$ define/nolog/user sys$input sys$command
$ java "''OPT'" -cp "''CP'" "org.tmatesoft.svn.cli.SVN" "''P1'" "''P2'"

[Ben Armstrong]

I can confirm that DECC$PIPE_BUFFER_SIZE = 32767 is needed. Before I defined this, an SVN diff would give me a stack dump in java$java_shr UNIXPROCESS_MD remapPath (I will not clutter the thread with the whole traceback, but can post it if anyone wants to investigate further).

But I have a more fundamental problem. Without privs turned on, jsvn creates read-only files when I do a checkout which then cannot be renamed, e.g.

$ jsvn co svn://ntts/dyserver
svn: Error writing entries file for '/DKC200/DYMAX/BG/./dyserver'
svn: Cannot rename file '/DKC200/DYMAX/BG/./dyserver/_svn/tmp/entries' to '/DKC200/DYMAX/BG/./dyserver/_svn/entries'

This would appear to be a difference in assumed Unix filesystem semantics from VMS. In Unix you ought to be able to set a file read-only and then rename it. It is the permissions on the *directory* that govern whether or not you can rename files. Not so on VMS. If you set a file read-only, it cannot be renamed. I don't know how to fix this. Obviously endowing all developers with system privileges so that they can rename their own read-only files is not a solution. Can someone please help?

Thanks,
Ben

[Ben Armstrong]

I have further confirmed basic Subversion client functionality working with OpenVMS V8.3 Alpha, Java 1.5.0-3 and SvnKit 1.1.7 (released 11 Apr 2008, 19:07! lucky timing on my part, I guess).

I have tried:
jsvn import
jsvn checkout
jsvn add
jsvn commit
jsvn update
jsvn diff

Also: checkout twice and commit a conflicting change

jsvn update ! reports C & adds merge markers
resolve the conflict
jsvn resolved
jsvn commit

[Larry Bohan]

I was (seemingly) able to work past the check-out read-only problem using the following DECC$ feature logicals. (below)

it was/is of interest to me, to find out
what decc$, and java$ feature logicals
folks have found to useful/helpful.
(John Malmberg has a conference (PORTING_TO_VMS) on the encompasserve Notes server, that may be of interest)

Are you using SVNkit primarily from DCL
or from the GNV bash shell? (just curious)

See also:
http://www.openvms.compaq.com/doc/83final/5763/5763pro_005.html
(the formatting is screwy, when usingFireFox.
slightly better when using the IE-Tab add-on)

DECC$UMASK

DECC$UMASK specifies the default value for the permission maskumask. By default, a parent C program sets theumask from the RMS default permissions for the process. A child process inherits the parent's value forumask.

To enter the value as an octal value, add the leading zero; otherwise,it is translated as a decimal value. For example:

$ DEFINE DECC$UMASK 026

DECC$FILE_PERMISSION_UNIX

With DECC$FILE_PERMISSION_UNIX enabled, the file permissions for newfiles and directories are set according to the file creation mode andumask. This includes mode 0777. When an earlier version of the file exists,the file permissions for the new file are inherited from the earlierversion. This mode sets DELETE permission for a new directory whenWRITE permission is enabled.

With DECC$FILE_PERMISSION_UNIX disabled, modes 0 and 0777 indicateusing RMS default protection or protection from the previous version ofthe file. Permissions for new directories also follow OpenVMS rules,including disabling DELETE permissions.

[Ben Armstrong]

I'm using SVNkit from DCL.

Even with a very permissive DECC$UMASK (000) and DECC$FILE_PERMISSION_UNIX enabled, I still get the same error. I guess regardless of my umask, jsvn wants to set the file permissions read-only for the entries file. Since write permission isn't specified, implied delete isn't relevant. Nor is inheriting permissions from an earlier version of the file relevant since in a checkout, all files are new.

So while I appreciate the tips, I still don't have a solution yet from the information you provided. I will have a look at the doc you referred to, though, and see if I can figure it out.

Thanks,
Ben

[Heinz Huber]

Our current settings for svnkit:
$ set proc/parse=extended
$ JAVA$M_UNIX_AND_VMS = 8
$ DEFINE/JOB/nolog JAVA$FILENAME_CONTROLS 'JAVA$M_UNIX_AND_VMS'
$ define/job/nolog DECC$ARGV_PARSE_STYLE ENABLE ! preserve argv case
$ define/job/nolog DECC$EFS_CASE_PRESERVE ENABLE ! enable ODS-5 names
$ define/job/nolog DECC$EFS_CASE_SPECIAL ENABLE ! enable ODS-5 names
$ define/job/nolog DECC$EFS_CHARSET ENABLE ! enable ODS-5 names
$ @dsa1:[java.jre1503.lib]java$150_jre_setup FAST


Seems to work.
Only two problems:
1) After checkout, update doesn't work on the root directory of the checkout.
2) Java translates file names with more than one dot in a lossy fashion (all but one dot are converted to underscores instead of ^.). svnkit can handle these files without a problem since it gets the correct names from it's svn-files. But other apps have problems if they need more than one dot.

[Larry Bohan]

Ben, sorry I wasted your time; I went back
to double check, turns out i was mixing priv'ed/non-prived sessions.

It does look like a delete ACL is needed
as a work-around. (just now, i recall
a similar issue doing svn client tasks against a AdvancedServer share)

[Ben Armstrong]

Heinz,

Why do you need this line?

$ define/job/nolog DECC$EFS_CASE_SPECIAL ENABLE ! enable ODS-5 names

If I execute @jsvnsetup.openvms in the svnkit 1.1.7 release it complains:

JSVNSETUP: DECC$EFS_CASE_SPECIAL defined! Please deassign logical otherwise jsvn might not function properly!

So I have commented this out in my setup with no ill effects.

What do you mean by "After checkout, update doesn't work on the root directory of the checkout."? I have no problem updating in the root directory of the checkout. What happens when you try this?

Larry,

OK. I have set up an ACL and now everything works! Thanks.

The only remaining mystery is that somehow in some of my commits I ended up with strange characters introduced into my text files (NUL, VT) at the beginning and end of each line. But since I changed quite a number of different settings during the course of my tests, I'm waiting to see now if I can reproduce the problem before pursuing it further.

Ben

[Ben Armstrong]

Here's my current shortcut for svn:

SVN == "pipe define/user sys$login DYM$USRACCT:[BG] ;define/user JAVA$FILENAME_CONTROLS 8 ;define/user DECC$ARGV_PARSE_STYLE ENABLE ; define/user DECC$EFS_CA
SE_PRESERVE ENABLE ; define/user DECC$EFS_CHARSET ENABLE ; jsvn"

The SYS$LOGIN thing is a bit specific to our environment, but the rest are all logicals discussed here. Using PIPE and user-mode logical names does away saves me from "tainting" my login session with logicals that may cause unexpected behaviours in other apps and does with the need for a DCL wrapper which would otherwise mangle the parameter list by uppercasing all commands.

My problem now is that while I have enabled DECC$ARGV_PARSE_STYLE, when I test this, case does not seem to be perserved, e.g.

$ svn co svn://ntts/RubyDyLib/trunk dylib
svn: URL 'svn://ntts/rubydylib/trunk' doesn't exist

But if I put double-quotes around the svn address, the checkout proceeds without further errors. So what's going on, here? Are there actually multiple image invocations when I execute 'jsvn' so that the user-mode logical isn't defined when it is needed?

Ben

[Ben Armstrong]

Argh. This forum system needs a way to edit posts. I meant "... does away with the need for a DCL ...", of course.