Mark Wilkinson writes:

> Following on from reading the "HP3000 open source" article on the interex
> website I found my way to the following page (even though in the FAQ
> information, checking out the source code is done with CVS whatever
> that is..)
...

I'll respond to the CVS part in a moment, but as it's a bit long,
allow me to make a couple brief comments on something else.


> I see that the vast majority of the form is devoted to collecting
> demographic information. IMHO, this is a bit "off". I know it's
> optional but why is it there in the first place.

I think you've heard my feelings on demographics before, so I shant
bore you with them again.  While I have a general understanding of
the demographics request in the first place, I should point out that
Interex's request for such is NOT always optional.  In fact, it's the
reason why I'm not attending the HPWorld Expo ("free" expo pass
notwithstanding).


Back to the CVS question.

Following is from my rambling IPROF post from 2/21 of this year:

-----

7. The POSIX-porting seminar also noted the existence of CVS
   (Concurrent Versioning System) on the 3000.  This is built on
   top of RCS (Revision Control System), and is a way of tracking
   changes to source files automagically.  Mark Klein ported it
   as part of the GNU C++ compiler.  IIRC, it is installed with
   the "GNUCORE" files.

   The big advantage to CVS is, as its names implies, concurrency.
   That is, even though user Jack has KEYCODE.SOURCE checked out
   for modification, user Jill can do this as well.  CVS assists
   with merging any changes.

   The other big deal is that there is distinct provision for
   vendor versions as well as user versions.

                       /
          vendor    v1.1
         version   /
                 /
              v1.01
             /
           /___a__b___c__

             user version


   Below is an example of what COULD have happened when porting Java.
   (No doubt actual events were significantly different.)

   HP starts with version 1.01 of the product, and introduces it to CVS.
   HP makes several mods to the product, shown here as releases 'a' and
   'b'.  When Java 1.1 comes out, it is imported into CVS (coincidentally
   via the 'cvs import' command).  At this point, CVS can tell what
   changed between Java 1.01 and 1.1, *and* what changes were made
   to Java 1.01 by the user.  Using this knowledge, CVS can help to
   merge the "official" changes in with the user's changes.

-----

Mark Klein quoted this last paragraph latter that day, and added:

   Actually, this is exactly what happens, and it is the fact that CVS is
   an important part of the process that allows a new port to take only
   a week. That does assume that the changes between releases are not
   major functionality that would require MPE specific changes. CVS aids
   in merging the MPE specific things we did "in the beginning" with the
   current release from Sun.

-----

Hope this helps.

--Glenn