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 [off-list ref]
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 [off-list ref]
$ 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

Ben Armstrong [off-list ref] wrote:

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.

Wow.

I'm talking to some folks who are trying to put JGit into Maven.
They want to move a lot of egit.core down into JGit, which should
make it easier to add more commands to the jgit wrapper, making a
more functional command line tool.
 

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

...

$ HELP EXT_FILE_SPECS Using File_Specification_Differences
ODS-5_Syntax Interpretation_of_Period
...
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.

Can you write a subclass of our FS class that can identify a
VMS host and use that VMS specific subclass? 

If so, we could add a method, e.g.:

  boolean canBeLooseRef(String name)

and on VMS when the name falls into that "ODS-5_Syntax
Interpretation_of_Period" rule set above, we could return false.
This would then permit a simple change in RefDatabase where we always
store such refs in the packed-refs file, instead of as a loose file.

It also means we'd have to forgo the ref log, or mangle the reflog
name.

But it seems to me we could reasonably work around this without
too much trouble.

-- 
Shawn.

torsdag 30 april 2009 17:39:36 skrev Ben Armstrong [off-list ref]:

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.

	O_o

Not sure what to say here.. cool. I never even thought of VMS as a Java platform.

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

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"

After googling a little, I think you got JAVA$FILENAME_CONTROLS wrong.
8 is for basic unix filenames. But you also need %x00200000 (or possibly
%x00100000) as well. See
http://h18012.www1.hp.com/java/documentation/1.5.0/ivms/docs/user_guide.html#unix_style

That's my guess....  I wouldn't dare to tell you how to get the exact syntax right, My VMS 
skillz are not what they once were.

Come to think of it, the first VMS machine I used was named "Linus", named
after a widely known character (in a comic strip called Snoopy). </anecdotes>

-- robin