Re: CVS -- RCS, CVS, Subversions, GNU Coding Standards, etc...

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Wed, 2004-10-27 at 00:36, Ken Keefe wrote: 
> I am about to begin an open source project and I figured that if I am
> going to do something, I ought to do it right! Anyway, I'd like to get a
> simple CVS server set up but I don't know where to begin...

You don't necessarily have to setup CVS.  CVS stands for "Concurrent
Versions System" and solved a lot of issues with concurrent development.
If it is just yourself to start, you can use RCS.  CVS (among countless
CM, configuration management, systems) is built on RCS (first as scripts
around RCS, like many systems, but fully integrated now for the last
half-decade).

If you are new to configuration management concepts in general, RCS
is a good start.  RCS is simple.  It's designed for a single user, with
the ",v" (delta) files stored locally (in a ./RCS subdirectory, if
created).  For more, see "man 1 rcsintro".

Also, rcsintro(1),   co(1),   ci(1),   ident(1),   rcsclean(1), 
      rcsdiff(1), rcsmerge(1), rlog(1), rcsfile(5), rcs(1)

There are a few, older RCS equivalents (like SCCS), but RCS and ",v" files
seem to be the defacto-standard when it comes to any base terminology,
approach and considerations in the Freedomware world.  So even if you use
another system, the RCS concepts are used.

CVS (among other systems) relocate these ",v" files to a more "centralized"
repository.  From there, it's a matter of system terminology differences,
implementation preferences, etc...  Sometimes the terms conflict between
systems.

But if you plan on releasing this publicly, and allowing others to work
on it, then you want to learn CVS.  The _best_way_ to learn how to setup
a CVS project is to look at what someone else is doing.  Find a project,
do a "cvs co" from their server, and look around at what files they put
in it, how they are formatted, etc...

Most of these are covered in various GNU guidelines, like the "GNU
Coding Standards":  
  http://www.gnu.org/prep/standards/  

> Are there different CVS server daemons and which one do you recommend

There is only _one_ CVS daemon.  Whether you use it or not is up to you.
There are ways to do CVS without the daemon, even over the network.
RSH/SSH, direct tree/NFS access, etc...  The CVS daemon is really only
needed on the server if you want to do password, Kerberos or other access.

Any method should do.  The only time the daemon becomes an issue is if
you are committing _massive_ sized files.  E.g., from personal experience
in committing 500MB files (an 8-bit microcontroller in a hardware
description language), if you go the daemon route, make sure you have
_lots_ of server memory.  Otherwise use NFS which is much faster and
doesn't kill your server (but that's only for _internal_ development).

> Hopefully they have books

There are _tons_ of books on configuration management (CM).  CM is a huge
enterprise onto itself and <high horse>CM is a concept that should be
_integral_ to system administration as much as development</high horse>.

E.g., merely using "ci/co" (RCS) on files in /etc goes a _long_way_ to
not only keeping control of configuration changes, but CYA (covering your
ass) when some manager or Windows puke says, "oh, you changed something"
(like DNS).  And I can turn around and go, "here are my DNS changes for
the last 6 months -- so where is your change log for your Windows Exchange
server?"  Gotcha (this was a first-hand experience where I kept getting
blamed for MX record changes, the problem actually ended up being a RFC822
non-compliance issue with Exchange that has 3 full exploits now)!

Probably the _first_book_ you'll want on CVS is Cederqvist:  
  http://www.cvshome.org/docs/manual/  

> and hopefully those books are on safari books online.

Yes, O'Reilly produces several.

A legacy book is RCS and SCCS:  
  http://www.oreilly.com/catalog/rcs/index.html  

The main CVS book from O'Reilly (and in Safari) is here:  
  http://www.oreilly.com/catalog/cvs/index.html  

A quick intro to CVS "user" commands is here:  
  http://www.linuxdevcenter.com/pub/a/linux/2002/01/03/cvs_intro.html  

> I've used CVS before, so I understand the basic concepts, but I have
> never run a CVS server.

Oh, you're ahead of the game then.
It's just a matter of creating the repository then.
This is nothing more than an "-i" to create the tree.

Now there are some considerations for setting up user-space.
You might want to create a variable and/or alias or two.
But that's about it.

There is also Subversions.
Subversions provides a CVS "user" compatible binary.
But the back-end is radically different.

Subversions' back-end has 2 major advantages for CVS:  
1)  Subversions offers full atomicity for commits (w/DB)
2)  Subversions offers a WebDAV facility (c/o Apache 2)

#2 is more preferred by web developers, but it can be advantageous for
browsing the tree.  It's added setup, but it might be worth it.

#1 is my favorite.  I _hate_ cleaning up CVS mis-commits.  Most of the
time, they are quick and easy.  But sometimes, they are a PITA.

Now I'm used to mega-heavy CVS traffic (large-scale defense systems code
or, even far worse, semiconductor HDL).  So CVS might do for you on a
much smaller scale.


On Wed, 2004-10-27 at 01:13, Casey Boone wrote:
> IANACVSU (i am not a cvs user *grin*) but i do know that quite a few
> ppl i talk to online who are like subversion better than cvs

Of course, because Subversions offers a WebDAV interface.
At the same time, it offers a CVS "user" compatible binary, so
there is no change from the traditional "user" experience too.

> i dont think there is more than 1 cvs daemon, although there is
> definately more than one VCS (version control system)
> if you are using fedora you should be able to install subversion and
> cvs both via apt/yum

Yep.


On Wed, 2004-10-27 at 00:36, Ken Keefe wrote: 
> Also, this is my first OSS project. Any suggestions, reads, legal
> advice, and so on would be greatly appreciated. 

If you are going the C/traditional language route, the GNU Coding
Standards are _crucial_.  It's not just about formatting, but about
lots of issues that 98% of Windows developers are _totally_ignorant_
of, such as data alignment, endianness and byte order.  If you want
your codebase to be not only portable, but last a long time, then
you want to make sure you are aware of these details.
  http://www.gnu.org/prep/standards/standards.html

Otherwise (from an article I am writing on software licenses):  

--- BEGIN ARTICLE SNIPPET ---

"ArchPI" is an unintentional Hostageware strategy, found largely
on software developed for the IA-32 (x86) platform, where 
the vendor writes code that is tied to the offerings of 
a particular architecture that is not implemented in 
others. In the case of IA-32, use of binary records and 
total ignorance of data alignment, endianness and byte 
order is absolute (a discussion of these concepts is beyond
this article, but understand even some developers have 
no idea what I am talking about, hence the problem).

* Software becomes not only processor specific, but 
  Application Programmer Interface (API) changes are 
  impossible unless they are architecturally compatible

  * Portage of software is a major undertaking, 
    requiring major new code to be written to handle 
    data alignment, endianness and order requirements 

  * A port is often incompatible with the original 
    version, you may be able to send documents to the 
    port, but going back to the original is difficult

* A change or patch to how a compiler (which turns 
  source code into machine-usable object code) 
  optimizes the organization binary data can render 
  even the same version incompatible

  * A compiler may now which to change the storage 
    order of a binary data record for performance improvements

  * This was commonplace in the version 6.0 release of 
    an application, where a, b and c revisions resulted 
    in third parties offering programs to translate formats

* Workarounds are made with library translators and 
  run-time implementations that simulate the original environment

  * The original environment is emulated, to guarantee 
    full data alignment, endianness and order requirements

  * Not only did the original 32-bit version of a 
    popular OS used a 16-bit on 32-bit execution 
    environment, but the new 64-bit version does the 
    same, with the corresponding reduction in 
    performance (far slower than the original, older OS)

Even when Hostageware vendors consider changing their 
Backone strategy, backward compatibility becomes near 
impossible. This is especially the case where their 
entire API is built upon the data alignment, endianness 
and order requirements, ArchPI, of a specific 16-bit 
and, later, 32-bit platform. Even when the vendor 
attempts to introduce a 64-bit "clean" API that is more 
security conscience, it suffers the same fate as its 
prior 32-bit attempts coming from an application space 
dominated by a 16-bit ArchPI codebase.

As much as one vendor attempts to blame its Independent 
Software Vendors (ISV) for continued proliferation of 
its ArchPI issues, one only needs to look at the 
vendor's own application development devision to see 
continued use of 32-bit and even still 16-bit ArchPI in 
version 6.0 of a popular Rapid Application Developer 
(RAD) system. The result is that its current, next 
generation OS being developed by one major company is 
often being compared to the same failed attempt 10 
years prior, "Cairo." For those around the time of "Cario," 
if you haven't had this Epiphany yet, think about the 
vendor's new term "FX technology" to get people focused 
away from the codename, which is suffering the same 
fate as "Cairo" due largely to unintentional ArchPI 
proliferation in its own organization.

--- END SNIPPET ---


-- 
Bryan J. Smith                                  b.j.smith@ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.