Maintaining CVS

[Ravi Shankar]

Dear all,

I do work in a moderately medium company with staff of about 500. We have a
separate division called Technology Development, which provided horizontal
services to verticals like Trade, Helathcare, Government, Legat etc.

In Technology Development (TD), we have 30 different teams distributed
across Singapore and India offices. We would like to maintain CVS for our
sources. Can anyone from such big enterprises help please on the following?

1) For enterprise applications, can we keep images, javascripts, jar files,
war files etc in CVS? Or just the source ? If so where we should keep the
rest ?

2) Should Indian office and Singapore office have one CVS ? Or should we
maintain two separate repositories ?

3) Should the CVS login ID be in terms of the developer name id or project
id?

4) Should there be any clean up tasks for CVS?

5) Is there any alternate that CVS ? For example I heard SUN is dealing with
thousands of builds in SUBVERSION, not CVS. Whats your suggestion?

Please help. Thanks a million for your time.

Best regards,
Ravi

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

5) Is there any alternate that CVS ? For example I heard SUN is
dealing with thousands of builds in SUBVERSION, not CVS. Whats your
suggestion?

I've used CVS for years and it is a great tool, but it isn't perfectly
suited to Java, or large projects. In Java class names are mirrored by
filenames. Every time you change a class name you also rename a file.
CVS does not support renames. Moving files around between directories
is also not supported. In fact, directories are not versioned at all.
Dealing with binary files under CVS is a pain and ultimately ends up
with a new copy being stored every time a binary file changes. CVS
commits are not atomic. That means that if something goes wrong in the
middle of a commit some files may end up being committed and others not.

All of these problems and several others are solved by Subversion. In
addition the tagging, branching and version numbers simply make more
sense in Subversion and are easier to handle.

It is a much better tool and is intended to be the upgrade path from CVS.
You might also look into arch. I don't know enough about arch to
intelligently discuss it, but it is an alternative to subversion. The
Linux developers also have been developing their own tool, but I don't
know anything about it either.

Subversion would be the natural choice.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDWcLmi2ZgbrTULjoRAkqpAKDjwpiYotUBuTm9qPqyQUZqJ357xgCePZyS
3avBpzhF/L+lK+lW9f27HSc=
=l7PY
-----END PGP SIGNATURE-----

 

[Roedy Green]

1) For enterprise applications, can we keep images, javascripts, jar files,
war files etc in CVS? Or just the source ? If so where we should keep the
rest ?

Yes you can. However you need to identify the files as either text or
binary, usually using a configuration of binary/text extensions.

binary updates are not diffable the way lines are.

 

[Roedy Green]

2) Should Indian office and Singapore office have one CVS ? Or should we
maintain two separate repositories ?

It depends. You probably want all three. One for Singapore projects,
one for India projects and one for projects with members from both.

It is nice to have your CVS server locally on a LAN near the biggest
concentration of programmers for fast access.

 

[Roedy Green]

3) Should the CVS login ID be in terms of the developer name id or project
id?

There are a ton of ways of doing login. For ease of use and maximum
privacy, one possibility is having each machine having a private
certificate for auto login, over an encrypted channel.

That presumes your programmer machines are physically secure.

Your biggest practical danger comes from a disgruntled insider
deliberately and subtlely corrupting the repository and the backups.

 

[Roedy Green]

4) Should there be any clean up tasks for CVS?

One big problem with CVS is checkin is not atomic. If something goes
wrong part way through your checkin, half of it will be in and half
not. That leaves the repository in an inconsistent state that will
sometimes bring everyone else to their knees who has done a checkout.
If they don't understand what has happened they might not recover on
their own until the original programmer recovers from his problem. The
problem magnifies with team size.

Subversion is a CVS competitor that deals with that problem.

Another problem with CVS is false deltas. Somebody adds a space or
breaks a line and it registers as a change when it really was not. It
then becomes hard to find the real changes in the noise.

The solution is to insist that all code go through standard
beautification before checkin. You can do this with an common
enforced Eclipse beautification configuration for example.

See http://mindprod.com/jgloss/cvs.html for more background.

 

[Roedy Green]

5) Is there any alternate that CVS ? For example I heard SUN is dealing with
thousands of builds in SUBVERSION, not CVS. Whats your suggestion?

CVS is well known and has hooks for example in Eclipse. It is a bit
long in the tooth.

Subversion is the up and comer.

The others are too expensive for individuals. They may be just what
you need though. I have links at http://mindprod.com/jgloss/cvs.html

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 22 Oct 2005 12:03:56 +0800, "Ravi Shankar"
Your biggest practical danger comes from a disgruntled insider
deliberately and subtlely corrupting the repository and the backups.

That is probably more likely to happen before the disgruntled former
employee became a former employee. I've wondered about why companies
treat people like they are going to screw them on the way out the door and
I've come to couple conclusions.

1) Many times the companies really have screwed their employee so they
expect revenge of some sort.

2) It makes it easier to deal with employees that stay if you assassinate
the character of those that left, and besides, they aren't there to defend
themselves. The fact that you had have security escort them out makes
them look at best suspicious in their coworker's eyes.

3) Sour grapes. When the employer can't keep someone they would like to,
or when someone's departure points out process problems they have been
complaining about forever, perhaps the best way to handle thing is to swat
them as hard as you can with whatever you can. 3 2 1... calling security.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDWeCoi2ZgbrTULjoRAk4lAJ9MefVc54/sx/9PJWr6RfT2Xp0JZwCcCEry
k1ugPht2qAztwxkcahWlzWE=
=WFW3
-----END PGP SIGNATURE-----

 

[Alan Krueger]

Subversion is a CVS competitor that deals with that problem.

It may also be worth mentioning that Subversion is usually considered to
be the successor to CVS, since I don't believe CVS is under active
development and many of the CVS developers have moved on to developing
Subversion.