Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Revision control (was: Re: VSS for WO/PB/Eclipse [NEWBIE])

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Revision control (was: Re: VSS for WO/PB/Eclipse [NEWBIE])

Subject: Revision control (was: Re: VSS for WO/PB/Eclipse [NEWBIE])
From: "b.bum" <email@hidden>
Date: Thu, 31 Jul 2003 12:08:09 -0400

Ahhh... a CVS conversation. Can't let that go by without posting something.

Enclosed is a message that I recently posted to the other webobjects-dev mailing list. It was in response to someone who was tangling with cvswrappers (in short: don't).

Before anyone reads this and thinks that it should be considered as a recommendation against using CVS, let me clarify something. I use CVS religiously -- have used CVS for more than a decade, have contributed patches to the source, and have often been in the unenviable position of maintaining the "somewhat definitive" build for developers from the NeXT community (tar wrappers and Windows builds, mostly) with a bunch of help from folks that are still my friends after having had to deal with CVS's source.

CVS sucks but it sucks less than anything else. I have used many other revision control systems and they all have annoyed me more than CVS.

CVS has several distinct advantages. It is open source -- i.e. you can fix it when it screws up. The repository is in a human readable format -- i.e. you can fix it when it screws up. There are about a bazillion people using it -- i.e. you can ask for, and will receive, help when it screws up. If you follow the rules-- some of which are not so obvious-- it generally just works and you don't actually have to deal with fixing it because it rarely screws up.

I'm looking forward to the day when I never have to use CVS again. Until then, I will continue to use CVS with confidence that it works and with the knowledge that I have everything necessary to fix it when it screws up. Proprietary / commercial solutions do not offer that flexibility even in the rare case where they actually work.

b.bum

On Wednesday, July 23, 2003, at 12:02 PM, email@hidden wrote:

We needed the cvswrappers file in that release.

You really, really, really do not want to use cvswrappers. Cvs wrappers are a pathetically evil hack that has never had support from the cvs maintainers and, as such, has always been this really nasty set of patches glommed onto CVS by a series of developers that were forced into doing so due to the realities of development on their particular PLaTFORM of choice.

CVS itself is a an excellent example of everything that is wrong with the "unplanned chaotic evolution" software development process.

But, yet, it currently sucks less than anything else (including perforce -- at least with CVS, you have access to the source for those times when it completely screws up), the price can't be beat, and it works [relatively speaking] everywhere.

The trick with CVS is to zen with the randomness of its implementation. Some hints:

(1) don't use pserver unless you are on a secure LAN. Pserver is insecure. Period. In a networked context, pserver is useful for anonymous access.

(2) always use the same method of accessing your repository. Always. CVS behaves subtly differently depending on how the repository is accessed.

(3) = 1+2. This leaves remote access via "RSH" -- but don't use RSH. Use ssh by setting the CVS_RSH environment variable to 'ssh'. (SSHPassKey can help). Always use ssh to access your repository -- even if it is local and especially if you do have to use wrappers for any reason.

(4) Don't use cvswrappers for anything but to specify what types of files should be handled as binary. The cvswrappers included with the OS X development tools is wrong; eomodels, wo components, and interface builder files do not need to be wrapped. They should not be wrapped.

(5) cvs conflicts in your pbproj (or eomodel) will suck away your will to live. Avoid them at all cost. A real-world token is effective. Grab some kind of children's toy that won't roll away or is not too tempting to throw and write PBPROJ on it. The developer in possession of said toy is the only one permitted to commit a change to the pbproj-- any developer not in possession who commits a change must resolve the conflict (which will never be on their machine -- such is the joy of revision control).

(6) Don't use cvswrappers (for anything but binary files). The latest releases of CVS do not support tar wrappers-- the -t / -f flags-- and, as such, using cvswrappers guarantees that you will have to maintain an outdated version of cvs. This causes hell. In particular, it means that you constantly have to move ~/.cvswrappers in/out if you want to interact with one repository that uses wrappers (-t/-f) and another repository [like sourceforge] that uses a modern version of CVS. It is unlikely that wrappers will be rolled forward to a newer version of CVS because the CVS source code is so painful to deal with.

(7) Check out a copy of the CVSROOT of your repository somewhere and then ln -s CVSROOT/cvswrappers ~/.cvswrappers. Depending on the operation, CVS will use ~/.cvswrappers instead of the remote cvswrappers found in the CVSROOT. Did I mention that cvswrappers are a disgusting hack the behaves inconsistently?

(8) Know how to use CVS from the command line. Accept that you will have to as a part of your reality. Life goes on. 'cvs add foo.wo/*.*' is your friend.

(9) When doing a "Save As..." in the varioues tools, it is quite likely that the CVS administrative directory within the component/file/interface will be carried along. Forgetting about this and doing a cvs add *.* within that directory will cause very, very bad things to happen. Very bad. Really really horrible. Remember to remove that directory from the copy first. If you forget, think very carefully about what happened before you attempt to fix it. Then check out a new work area and fix the problem there.

(10) rm -rf is your friend. If a hunk of your workarea seems to have blown up, is out of sync, has changes that you don't want.... kill it and 'cvs -q update -dP'. If you encounter a conflict, it is often easiest to blow away the conflicting piece, update, and reapply your changes -- certainly is for pbproj files!

If you do a search of google or the archives of this list, I have posted a number of other tips over the years. As CVS hasn't actually changed in years, they are still completely relevant.

b.bum (Who apologizes again for the role I have played in perpetuating the madness that is cvs wrappers...) _______________________________________________ webobjects-dev mailing list | email@hidden Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev Do not post admin requests to the list. They will be ignored.

Follow-Ups:
- Re: Revision control (was: Re: VSS for WO/PB/Eclipse [NEWBIE])
  - From: Arturo Pérez <email@hidden>

References:
	>Re: VSS for WO/PB/Eclipse [NEWBIE] (From: Chris Hanson <email@hidden>)

Prev by Date: Re: VSS for WO/PB/Eclipse [NEWBIE]
Next by Date: Re: Correctly Updating Objects
Previous by thread: Re: VSS for WO/PB/Eclipse [NEWBIE]
Next by thread: Re: Revision control (was: Re: VSS for WO/PB/Eclipse [NEWBIE])
Index(es):
- Date
- Thread