NOTE: When I say CVS I mean CVS and comparable solutions...

Touching on this some gave me an idea about some of the other issues
being
discussed.

Would it be possible for newCo to use three basic levels here?

1) The core engine team could continue using the Marion source control
system.
2) The serious developers at large would be setup to operated through
the
CVS interface.
3) The not so serious could simply use email, word of mouth, etc.

The hard part would be getting the interface between Marion and CVS
all
setup and working without kinks. It would probably be a manual effort
getting started. But, using CVS to distill and organize the efforts of
the
masses could prove invaluable while maintaining the proven and custom
approach of Marion to oversee the internal developer tree. Seems like
it
could be a reasonable compromise to me...

--------
This was done once before -- the first LIBS ports were done via a team
working inside of CVS with a link to marion. A nightly script
performed a sync between the cvs and marion trees.
--------

My gut feel here is that Marion is well suited for a tight-knit
engineering
group to work with a large base of code. It probably has a lot of
built-in
mechanisms that cater to the development of InterBase. What it
apparently
doesn't do well is interface to the masses. Since it doesn't allow
anything
more than exclusive locks on files and because it won't merge them
automatically.

-------
The only thing Marion really has that is customized to InterBase is
some automatic "porting" -- things that could easily be done with sed
or perl scripts.
example:
Baseline stores
#include "source/jrd/jrd.h"
On NT, windows, etc, this is translated to
#include "../jrd/jrd.h"
On VMS this is translated to
#include "[source]:jrd/jrd.h"
On MPE/XL this is translated to
#include "jrd.hjrd"
(etc.)

When you check in, lines are translated from the platform specific
format back to the baseline format.
--------------------------


For me - the key thing is the interface between the open community and
Internal source tree. Someone mentioned that email diffs are used a
lot in the Linux community, and I agree with that. Changes need a
lot of review before they are merged into a master base -- so email
diffs are the way to do that. NewCo can use whatever makes sense
internally. There should also be a master "public tree" for
community submissions.

Key issue also: Coding style. The InterBase coding style is fairly
rigid, and different from many other code bases I've worked on. I am
a strong believer in consistency, however. Whenever there's a chunk
of code that is styled differently, I wonder about whether the author
really knew what they were doing. (This is simple things, like
indentation, spacing, and line breaks).

Dave



[This message contained attachments]