Well, I think the answer depends on your goals. CVST (I hope it's OK if I use it as a short for CVSTProj part of it in this message :-) is aiming at: 1) merging Smalltalk with the "source tree" style of projects. 2) portable framework allowing to run a project across several dialects.
For 1) I believe that file per class is a better match. More granular history of the project allows you to answer questions like "When was this class changed ? How many times ? ", allows rollback of individual classes, etc. Which I think are frequent enough to warrant the support. I don't find the argument about load ordering too strong, it's a pretty trivial algorithm, since with the built in Undeclared mechanism the class hierarchy is the only thing you really need to deal with. I admit that more frequent adds/removes/renames are additional overhead, but that's more CVS "feature" than anything else. Better SC tool will make that easier.
It seems to me that DVS is more focused on Squeak than on CVS and there's not as much drive to get as much out of the SC tool as you can. In which case file per package sounds reasonable too. I suspect that both DVS and CVST have a lot in common as they both synchronize the state in the image with the state in the source file tree (computing changes, applying them to the image or to the files, etc). To address goal 2) CVST adds flexible source code format support (you really have to use SIF to run cross-dialect at the moment) and explicit portability interfaces to aid porting efforts. I don't know how far is DVS in that area.
In any case DVS definitely does seem to have more drive behind it in the Squeak camp at the moment. The Squeak port of CVST is lagging behind the VW, VA and Dolphin ports by one version at the moment (as there was no Squeak person in our group at Camp Smalltalk 4 in Colorado) and I definitely won't have time to spend on it. Of course I am sorry to see CVST loosing in the Squeak circles, but that's natural when a more active alternative comes in. Especially if the alternative focuses on more urgent needs of the community.
Best regards,
Martin
Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk ----- Original Message ----- From: "Avi Bryant" avi@beta4.com To: squeak-dev@lists.squeakfoundation.org Sent: Monday, October 28, 2002 3:50 PM Subject: Re: Envy or Store or what?
On Mon, 28 Oct 2002, [ISO-8859-1] Göran Hultgren wrote:
What about that btw - what is your reasoning about having one file per package (instead of say one file per class)? It sort of "defeats" interesting properties in CVS I think.
But having one file per class defeats some nice properties of changesets - they impose an order on loading in classes (so you don't define a subclass before its superclass), they are easy to distribute and install, Squeak automatically deals with them even when compressed, etc.
Having too many files also makes CVS unwieldy - you always have to be doing adds and removes, revision numbers are on the class and not the entire package, and so on. And the major advantage - that conflicts are kept low - is taken care of fairly well by the order in which DVS files things out.
However, if sqcvs integration was done (so that adds and removes could be done automatically), and using .sar as a packaging format (and generating an install script that loaded everything in the right order), then it might make sense to finish working on the DirectoryPackageDumper, which files out each method and class definition as a separate file.
And another thing, what do you think about the "decisions about how we proceed with modules" I have been trying to get people buzzing about?
Well, I'm personally going to continue making 3.2 the best (as defined by "most useful to me") environment I can, without worrying for a moment about duplicating functionality that may or may not exist in 3.3a. Either everyone else will make roughly the same decision, or they won't.
Avi