jgit standalone client on OpenVMS works (somewhat)

I am happy to report that the jgit standalone client works (somewhat) on OpenVMS/Alpha, a non-POSIX platform for which no C git port exists. I understand that not all functionality of the C client is supported yet, but for limited use, and supplemented by using the C client on a PC, I may be able to get away with this. At least being able to do a 'git clone' is encouraging.

The only problem I have found so far is that if a tag has dots in it and the last dotted expression looks like a VMS file version number, it is interpreted as such instead of part of the filepath used to represent it under .git/refs/tags

I am using:
- egit v0.4.0.329.g06fc
- OpenVMS/Alpha V8.3
- Java 1.5.0-5

For the curious, this is what I have done so far to attempt to make jgit work on VMS.

1. On a Linux host, checkout egit and build the standalone jgit wrapper:

git clone git://repo.or.cz/egit.git cd egit ./make_jgit.sh

2. Copy the resulting 'jgit' script to VMS (samba S: is mapped to the VMS
    device DSA0:):

mkdir /s/dymax/jgit/ cp jgit /s/dymax/jgit/

3. On VMS, set up the jgit command environment appropriately:

$ define jgit_home dsa0:[dymax.jgit]
$ jgit==java+" -cp /jgit_home/jgit ""org.spearce.jgit.pgm.Main"""
$ git=="pipe define/user JAVA$FILENAME_CONTROLS 8 ; "+-
   "define/user DECC$ARGV_PARSE_STYLE ENABLE ; "+-
   "define/user DECC$EFS_CASE_PRESERVE ENABLE ; "+-
   "define/user DECC$EFS_CHARSET ENABLE ; jgit"

4. Set up a place to create workspaces with expected filesystem
    semantics on an ODS-5 volume (only allow one version of each file
    and allow read-only files to be renamed by all members of the [DV,*]
    security group, of which I am a member, otherwise git clone will fail):

$ set def [bg]
$ create/dir [.work]
$ set directory/ver=1 [.work]
$ set security/acl=(IDENTIFIER=[DV,*],OPTIONS=DEFAULT, -
   ACCESS=READ+WRITE+EXECUTE+DELETE) work.dir

5. change to the directory and perform a clone::

$ set def [bg.work]
$ git clone git://repo.or.cz/egit.git
Initialized empty Git repository in /DSA0/BG/WORK/egit/.git
Receiving objects:      100% (20983/20983)
Resolving deltas:       100% (11562/11562)
From git://repo.or.cz/egit.git
 * [new branch]      master     -> origin/master
 * [new branch]      stable     -> origin/stable
 * [new tag]         v0.1.1     -> v0.1.1
 * [new tag]         v0.2       -> v0.2
 ! [rejected]        v0.2.1     -> v0.2.1
 * [new tag]         v0.2.2     -> v0.2.2
 * [new tag]         v0.2.99.200709172321 -> v0.2.99.200709172321
 * [new tag]         v0.3.0     -> v0.3.0
 ! [rejected]        v0.3.1     -> v0.3.1
 * [new tag]         v0.4.0     -> v0.4.0

That doesn't look very nice ... see more notes on this below (step 7).

6. verify some things work:

$ git version
jgit version v0.4.0.329.g06fc
$ git branch
* master
  master.
$ git log -- .gitattributes
commit d4e240ab52a95dc22ae5abffdc6254b723285696
Author: Shawn O. Pearce <spearce@spearce.org>
Date:   Fri Aug 15 09:36:06 2008 -0600

    Enable diff=java for all *.java source files

    This (usually) gets more reasonable function headers to
    appear in the header line for a diff hunk.  Its slightly
    better than the default C rules.

    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
$ dir [.^.git]

Directory DSA0:[BG.WORK.egit.^.git]

branches.DIR;1 config.;3 FETCH_HEAD.;1 HEAD.;2 index.;1 logs.DIR;1 objects.DIR;1 refs.DIR;1 remotes.DIR;1 $ dir

Directory DSA0:[BG.WORK.egit]

^.git.DIR;1 .gitattributes;1 .gitignore;1 EGIT_INSTALL.;1 jgit-maven.DIR;1 jgit.sh;1 make_jgit.sh;1 org^.spearce^.egit-feature.DIR;1 org^.spearce^.egit-updatesite.DIR;1 org^.spearce^.egit^.core.DIR;1 org^.spearce^.egit^.core^.test.DIR;1 org^.spearce^.egit.DIR;1 org^.spearce^.egit^.ui.DIR;1 org^.spearce^.jgit.DIR;1 org^.spearce^.jgit^.pgm.DIR;1 org^.spearce^.jgit^.test.DIR;1 README.;1 SUBMITTING_PATCHES.;1 tag_egit.sh;1 TODO.;1 $ type .gitignore /jgit /jgit.jar /jgit_src.zip

7. see if we can sort out the tags issue:

$ git fetch -v fatal: /DSA0/bg/work/egit/./.git/logs/refs/tags/v0.2.1 (i/o error) fatal: Failure updating tracking ref refs/tags/v0.2.1: /DSA0/bg/work/egit/./.git/logs/refs/tags/v0.2.1 (i/o error) $ dir [.^.git.refs.tags]

Directory DSA0:[BG.WORK.egit.^.git.refs.tags]

v0.1;1 v0.2;2 v0^.2^.99.200709172321;1 v0.3;1 v0.4;1

Whoops, v.0.2.1 is missing.  And v0.2;2 looks suspicious.

$ git tag mytag $ dir [.^.git.refs.tags]

Directory DSA0:[BG.WORK.egit.^.git.refs.tags]

mytag.;1 v0.1;1 v0.2;2 v0^.2^.99.200709172321;1 v0.3;1 v0.4;1

Looks good.

$ git tag mytag.1.2 $ dir [.^.git.refs.tags]

Directory DSA0:[BG.WORK.egit.^.git.refs.tags]

mytag.;1 mytag.1;2 v0.1;1 v0.2;2 v0^.2^.99.200709172321;1 v0.3;1 v0.4;1

Total of 7 files.

Herein lies the problem. Apparently "mytag.1.2" is interpreted as the filepath mytag.1 revsion ;2

This is trivially reproduced using the native DCL "create" command:

$ create 1.2.3 test ^Z $ dir 1.2 Directory DSA0:[BG.WORK.egit]

1.2;3

Total of 1 file.

If I explicitly quote all dots but the last, it works:

$ create 1^.2.3 test ^Z $ dir 1^.2.3

Directory DSA0:[BG.WORK.egit]

1^.2.3;1

$ HELP EXT_FILE_SPECS Using File_Specification_Differences
ODS-5_Syntax Interpretation_of_Period
...
             The introduction of the period (.) as a literal character in
             extended file names requires RMS to determine which periods are
             file name characters and which are delimiters.

             When only one period (.) is used in an extended file name, that
             period is interpreted as the delimiter, as in "Venice.Venezia;1"
             above. As in previous versions of OpenVMS, this behavior also
             occurs if the single period is followed by a number:

             $ CREATE Test.1

             creates the file:

             Test.1;1

             When there are multiple periods (.) in a file name, the system
             looks at all the characters after the last period. If those
             characters are five or fewer digits, or a minus sign (-) followed
             by five or fewer digits, the period is interpreted as a version
             delimiter and the period previous to it is a type delimiter.
             Notice that a legal version is less than or equal to 32767.
             If you try to create the file "grandioso.x.33333", the "33333"
             causes an illegal version error. If there is a nonnumeric
             character following the last period then it is interpreted as
             a type delimiter.
...

Uggh. I don't know if I'm going to be able to solve this one. I guess I just have to avoid multiple periods in tags.

Ben