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@xxxxxxxxxxx>
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@xxxxxxxxxxx>
$ 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html