stat (AGAIN!)

[Jean-François PIÉRONNE]

"John E. Malmberg" wrote:
> 
> I had been looking at doing such a guide and part of that is in my
> frontport documentation.
> 
> I did the SAMBA 2.0.6 port and my early start at the 2.x and 3.x ports
> set up using search lists, where I kept the UNIX code in it's own
> separate directory tree, and then a CMS directory, plus a work
> directory.  This allows quick updates, but keeps it easy to track what
> has been changed and what is under test.
> 
> Where I got bogged down is that I am looking at a way to automatically
> update the UNIX directory tree with each change that was checked in.
> This would allow OpenVMS to join the SAMBA build farm.  By being a
> member of the build farm, if anyone checked in a change that broke the
> OpenVMS build, they would need to fix it.
> 

For the Python and MySQL port I have used the following method:
- each time I update a file I copy the original version into an other file
appending "$o" to its name.
- I run a Python script which walk recursively through the source directories
and generate using gnu diff:
   - a command procedure which:
       - apply using gnu patch all the patches
       - copy the original file into the same file appending "$o"
       - generate a gnu diff file for each file updated
       - generate a file containing using all the updates

So when I download a new version, I just run the generated procedure.

I do this for Python near each day, and I have ported the lastest MySQL release
in a couple of hours using this method.



> The tool to do that is RSYNC, but RSYNC has proven to be harder to port
> than SAMBA because it needs to fork() too often.  As a side though, I
> have ended up with a TPU program that can convert many UNIX man pages
> into OpenVMS help files, and Runoff documents, and a DCL program that
> can create the config.h file for a given OpenVMS release.
> 
> Then I found that there was a PYTHON version of Rsync, but that the
> Python port was not operational.  Jean-Francois Pieronne has remedied
> that for the most part, but I am trying to make things better with it's
> build.  I hope to be testing pysnc soon.
> 

Well, I tend to disagree, Python port is operational, the only known problems
are on non-blocking mode socket and into the sprintf port (VMS don't provide
snprintf) which appear to not correctly format some big number.
But the current port is based on 2.3 which is still under development.
Python pysync and rsync.py work but it seem that they don't include the server
part, only the client part.
I have test locally these two tools successfully.


Jean-François