From mboxrd@z Thu Jan  1 00:00:00 1970
From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rev control 
In-reply-to: Message from presotto@plan9.bell-labs.com 
   of "Tue, 02 Jan 2001 22:54:16 EST."References: <20010103035425.D50F1199E6@mail.cse.psu.edu> 
 <20010103035425.D50F1199E6@mail.cse.psu.edu> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17403.978496261.1@aubrey.stanford.edu>
Message-Id: <20010103043102.9EDED199DD@mail.cse.psu.edu>
Date: Tue,  2 Jan 2001 20:31:01 -0800
Topicbox-Message-UUID: 42672d8e-eac9-11e9-9e20-41e7f4b1d025

With a fairly small group of 15 where I work, handling around 200K lines
of code, I find the following trend with projects in CVS:

	people do make sure things compile, but don't necessarily make
	sure things work

	CVS diff is helpful, but it's still a pain in the ass to deal with merges

	at least it's more helpful than straight RCS since we each have our
	own play pen.  We only have to deal with merges when we've got a
	new feature or bug fix ready to commit back to production

	comments logged for commited code changes are useless one-liners like
	"changed stuff in function x" or "added feature y"

	differences in coding style makes sharing a tree a pain in the ass
	when it comes to doing the aforementioned diff.

Essentially, I don't see a whole lot of use in the system other than syncing
the project back into a main source tree. And that could be done with a few
shell scripts if all the other things like yesterday(1) and history(1) were
available to use on Unix.

My views would probably change with huge projects, but for medium size ones
I would prefer the plan 9 dump approach.


Jim