Hi

We have been using MS Source Safe for many years. It comes with VB professional .

We put many different languages, cmd files, job streams etc into Source Safe.

Multi-edit also links to Source safe. It is a very cool , cheap editor that does many things very well.
http://www.amcyber.com/new.htm

Ray


> ----------
> From:         Chuck Ryan[SMTP:[log in to unmask]]
> Sent:         Friday, September 08, 2000 7:25 AM
> Subject:      Re: SRC/ix
>
> > Jeff plugs CVS:
> >
> > >These days I use CVS on unix machines a lot and am pretty
> > happy with it.
> > >(I understand CVS is bundled with the GnuCore stuff that
> > Mark Klein has
> > >ported to MPE, though I've never used CVS on MPE.  If I were
> > trying to set
> > >up a new source management system on MPE today, I'd set up
> > CVS and see how
> > >well I could make that work.
> >
> > It actually works pretty darn well! The only reasons not to use it are
> > if you're concerned it preserving MPE file attributes and non-HFS
> > semantics. CVS is a POSIX application, creates byte stream files and
> > is case sensitive. But, for team or distributed development, it can't
> > be beat.
> >
> > Regards,
> >
> >
> > M.
> >
>
> Since our PC development team is using MS SourceSafe for its version
> control, I have begun experimenting with it to store my cobol source.
>
> So far It seems to work fine by having the SS database stored on an NT
> server with the Shadow and Working directories on the HP3000 via SAMBA
> shares. I created a couple of command files that convert between the
> bytestream and cobol formats and, even though I cannot compile directly from
> the Shadow directory, the process is not that bad.
>
> This also gives me a little more control as my developers can submit their
> changes to SS and I can compile and move them into production on the 3000 by
> simply copying the contents of the Shadow folders, with my conversion
> command files, and streaming the compile jobs. This will make the auditors
> happy since the developers, except of course myself, will not be able to
> touch production code.
>
> So far it seems to work well, now if I could just get around the limitations
> of MPE security it would be even easier.
>