Very Computer

I am looking for a recommendation as to what type of source code
management system to use for my informix-4gl applications.

I am currently running Informix 7.31 under HP-UX 11.  We have
approximately 5 developers that work on our 4GL applications.  I am
currently leaning towards SCCS since it is free and we are a small
shop.

Is it worth looking at other applications or does SCCS work fine.
Please keep in mind that I would like to keep the source code mgmt on
the UNIX box.

Let me know your thoughts.

Thanks,
Michele

RCS would be another possibility . . . .

We use a package from Unipress called SCM; great little package for UINX, but unfortunately it is not for sale.

Quote:>I am looking for a recommendation as to what type of source code
>management system to use for my informix-4gl applications.

>I am currently running Informix 7.31 under HP-UX 11.  We have
>approximately 5 developers that work on our 4GL applications.  I am
>currently leaning towards SCCS since it is free and we are a small
>shop.

>Is it worth looking at other applications or does SCCS work fine.
>Please keep in mind that I would like to keep the source code mgmt on
>the UNIX box.

>Let me know your thoughts.

>Thanks,
>Michele

Mike:

Have you looked at Source Safe? It's the only way to go. Trust me on
this one. There aren't any UNIX based source code mgmt systems worth
anything. (SCCS/RCS is garbage). Don't be a dinosaur. Think GUI.

I've looked at SourceSafe, and I've stuck with SCCS. It's the only way to go.
Trust me on this one. There aren't any MS-based source code management systems
worth anything. (SourceSafe in particular is garbage.) Don't be an idiot who
falls for flashy screens and clicky-icons. Think reliability. Think integration
with your current environment. Think script-ability. Think not having to poison
your environment with unreliable MS servers.

And don't feed the trolls.

While I don't have too much experience with this CVS seems to work quite
fine (and there are even some GUI wrappers if you like it). At least might
be worth to look for (it's also free).
                                            Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |          AG Moebius, Institut fuer Molekuelphysik
 | |_| |  | |    | |          Fachbereich Physik, Freie Universitaet Berlin
  \___/ens|_|homs|_|oerring   Tel: ++49 (0)30 838 - 53394 / FAX: - 56046

Both CVS and RCS are available for download from the GNU software
project at www.gnu.org

I prefer RCS over SCCS because of the way it stores changes.  SCCS
kept the very first version of the file along with a list of all the
changes required to get the latest version.  RCS saves the latest
version and keeps a list of the changes to get to the previous
version(s).  This means that SCCS can be quite slow when checking out
a file with lots of revisions, while RCS simply copies it out to the
working file.

I haven't used CVS here, so I can't comment on it.  I do know that
there are a variety of tools available for use with it, such as web
browser interfaces.

Have fun....Scott

I do not know any tool which does something special regarding informix.
So we can discuss about general purpose version control tools.

Quote:> I am currently running Informix 7.31 under HP-UX 11.  We have
> approximately 5 developers that work on our 4GL applications.  I am
> currently leaning towards SCCS since it is free and we are a small
> shop.

I would recommend you to take a look at CVS. It is completely free and
has far greater functionality than SCCS or RCS (RCS is the open source
vc system of similar functionality to SCCS but a bit newer, a bit faster
and a bit more polished). For instance, using CVS you can version
control removing a file, you can access the source code repository from
different machines creating many work areas, you can find a lot of tools
including GUIs...

Check out http://www.cvshome.org

Quote:

> Is it worth looking at other applications or does SCCS work fine.
> Please keep in mind that I would like to keep the source code mgmt on
> the UNIX box.

All the tools I mentioned work on Unix.

--
http://www.mk.w.pl /
 Marcin.Kasperski | Sztuczki i kruczki w C++:                        

  sm> I prefer RCS over SCCS because of the way it stores changes.  SCCS
  sm> kept the very first version of the file along with a list of all the
  sm> changes required to get the latest version.

This is a techno myth; it's oft repeated, but just not true.

SCCS uses interleaved deltas, which gives more-or-less constant-time
performance.

RCS will be faster checking out files nearer to the head of the main
branch, but will probably be slower than SCCS when checking out versions
on old branches.

However, in my experience, even on hardware that's quite modest by
today's standards you'll never notice the difference.

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

That is not a completely accurate characterization of the way SCCS
stores its information.  Specifically, SCCS does not have the
differences between versions in a separate section of the file as RCS
does; it keeps the delta information (actual file changes) distributed
throughout the file.

Quote:> RCS saves the latest
> version and keeps a list of the changes to get to the previous
> version(s).  This means that SCCS can be quite slow when checking out
> a file with lots of revisions, while RCS simply copies it out to the
> working file.

SCCS will always make a complete pass over the SCCS s-file; RCS does not
always have to read the whole of the RCS v-file, so there is some chance
that RCS will be quicker.  On the other hand, if you are collecting an
old version from RCS, there will be a sequence of diffs to apply; SCCS
stores the information such that it pulls exactly the required material
in the first pass.  I've never had problems with the speed of 'sccs
get', but nor have I had speed problems with the speed of 'co', despite
having worked on projects with contorted version histories and routine
scrutiny of ancient as well as modern versions of files.  So I tend to
regard this whole speed issue as something of a red herring.

Quote:> I haven't used CVS here, so I can't comment on it.  I do know that
> there are a variety of tools available for use with it, such as web
> browser interfaces.

CVS is widely used by Open Source projects; they can't all be wrong.
There's a replacement for CVS under development -- see
http://subversion.tigris.org/ -- which looks extremely interesting.

Personally, I prefer the SCCS system of keeping records of checkouts in
a separate file from the master source code; if the checkout is
subsequently cancelled, the s-file is not modified.  I dislike the
change in modification time of the v-file that results from making a
checkout under RCS, and doubly so when the checkout is cancelled.  That
is partly because I also prefer strict locking, which is the antithesis
of what CVS uses.  I also prefer the SCCS keyword system, but both that
and the RCS/CVS equivalent systems have their problems.

But you have to choose what will work for you, and any of the systems
mentioned with the probable exception of Visual Source Safe will work
with Informix 4GL -- VSS is not a good choice because I4GL is not
available for Win32 platforms except in the guise of D4GL, aka 4J's --
http://www.4js.com/.

However, as someone pointed out, if you use SCCS, ensure it is a
Y2K-compliant version of SCCS.  If you use an old version, you will
corrupt your s-files with punctuation characters where you should see
digits.

And, just for reference, most of my own code (as opposed to corporate
code) is under RCS because that is available on Linux (and CSSC, the GNU
variant of SCCS, is not wholly ready for production use), and because I
don't want to be stranded with a machine with a broken (non-Y2K safe)
version of SCCS.  Even so, I still prefer SCCS.

--
Yours,

Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN
     "I don't suffer from insanity; I enjoy every minute of it!"

Paul,

Nice to see someone who is familiar with SCCS!

For those of you not familiar with SCCS, some of the
other advantages that Paul didn't mention are:

    1) Checksums on the metadata file. RCS doesn't
       have this and there have been many cases where
       there is silent corruption of CVS repositories.
       Use google.com to look back on this newsgroup
       if you doubt this.

    2) Interleaved deltas allow for efficiently "turning off"
       previously committed deltas. Just a few bytes are needed
       to cancel the effects of a large delta whereas RCS
       would need to store the entire diffs of the change.

However, I won't disagree that RCS has an easier user interface.

Regards,
Aaron

SCCS and RCS are really low-level tools.  If you need a higher level
of abstraction, there's CVS (which uses RCS).  I don't know of a
comparable higher-level interface for SCCS.  Anyway, CVS has kept me
happy for the last decade.

Quote:> And don't feed the trolls.

Depends on what you feed 'em...  YMMV.

--
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412

President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Quote:>I prefer RCS over SCCS because of the way it stores changes.  SCCS
>kept the very first version of the file along with a list of all the
>changes required to get the latest version.  RCS saves the latest
>version and keeps a list of the changes to get to the previous
>version(s).  This means that

Emm, doesn't this imply (to paraphrase you) that:
"RCS can be quite slow when checking *IN*
"a file with lots of revisions?
Surely what you gain on the straights you lose on the roundabouts.

What annoys me about RCS is the way it only allocates the new version number
at check-in time, whereas with SCCS you can allocate the branch or node when
you checkout. When you are doing the work, you know whether you are
proceeding down a branch or starting a new one. With SCCS, you could emulate
the late-allocation of version number (simply take a cut and then mess with
version numbers at checkin time and nobody will be the wiser) but I can't
see how to allocate (reserve) the target version number at checkout time
with RCS. Have I missed something with RCS in this area? Please educate me!

RCS also seems to make it quite difficult to checkout from the same node. It
locks out a version and stops you making an emergency patch to the same
node. With SCCS it's trivial and closely matches an occasional need from the
real world. Once again, have I missed something with RCS?

Finally, RCS fans like to claim that SCCS cannot store arbitrary branching
structures or offer merging of selected notes back into any chosen stream.
Both claims are nonsense. SCCS version numbers are either A.B or A.B.C.D but
that doesn't preclude branching. If you wish to view a tree-like structure
of an SCCS tree I've got a trivial script for that. Regarding the merging
issue (and diffing as well) you only need to read the manual to discover the
solutions.

I wouldn't mind supporting RCS but I need these questions answered first.
--
I'd always thought music was too formal, and
I thought "well, I'll get into this and fix it"
    - Don Van Vliet
..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .

Oooh - talk dirty some more! I wish I had that factoid to splash around
about 6 months ago.

Quote:>RCS will be faster checking out files nearer to the head of the main
>branch, but will probably be slower than SCCS when checking out versions
>on old branches.

>However, in my experience, even on hardware that's quite modest by
>today's standards you'll never notice the difference.

Amen.

--
I'd always thought music was too formal, and
I thought "well, I'll get into this and fix it"
    - Don Van Vliet
..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .

I've had fairly good luck w/ cvs on my systems, but i've never had to
manage a cvs system w/ more than 4 or 5 people, things change when the
numbers get high.

i also hear good things about bitkeeper, but have never played around
with it.

Quote:> Have you looked at Source Safe? It's the only way to go. Trust me on
> this one. There aren't any UNIX based source code mgmt systems worth
> anything. (SCCS/RCS is garbage). Don't be a dinosaur. Think GUI.

sourcesafe is a pile of junk IMO stay as far away from it as possible.

  >>> Is it worth looking at other applications or does SCCS work fine.
  >>> Please keep in mind that I would like to keep the source code mgmt on
  >>> the UNIX box.

  mb> I've had fairly good luck w/ cvs on my systems, but i've never had
  mb> to manage a cvs system w/ more than 4 or 5 people, things change
  mb> when the numbers get high.

I don't think there's anything inherent in CVS that makes it not good
for larger groups.  It's just that as the use goes up the more likely it
is you'll run into something you need to admin the repository for.

  mb> i also hear good things about bitkeeper, but have never played
  mb> around with it.

BitKeeper looks cool; it's definitely worth a look, _esp._ if you have
distributed development.  It's not free software, but it's not very
expensive IIRC.

There's a new, free replacement for CVS that looks like it'll be da bomb
when it's done; check out Subversion (subversion.tigris.org).  As
described on the pages it fixes all my complaints about CVS.  And, it's
actually moving right along.  They hope to move to "self-hosting" this
month sometime.

  >> Have you looked at Source Safe? It's the only way to go. Trust me
  >> on this one. There aren't any UNIX based source code mgmt systems
  >> worth anything. (SCCS/RCS is garbage). Don't be a dinosaur. Think
  >> GUI.

  mb> sourcesafe is a pile of junk IMO stay as far away from it as
  mb> possible.

Agree 100%.  Friends don't let friends use SourceSafe.

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.