[Seaside] [DVS] Future of DVS & team source management?

[David Farber]

Avi - Ok, so I installed CVS on my system, loaded SqueakMap and DVS into my image and I'm ready to do some high-powered development backed up by solid source code management.

...And then I notice that DVS files out packages into a /single/ change set. Hmmmm. Well, that is certainly the simplest way to go about things. And everything works.

But, if I've only got one file, what do I need some big ol' source control system like CVS for?

I must admit that I wasn't exactly sure what I expected. When I've coded Smalltalk professionally in the past, I've always had Envy to manage my code. Whenever I'm hacking Java or Perl I always make a point of using CVS (as opposed to not using anything). Now that I think about it, change sets do tend to be almost random blobs of code--it seems like it would almost be like herding cats if you tried to seriously do source code management on some random number of change sets each containing some random chunk of code.

I guess what makes the most sense to me is that the "right" way to interface with a "traditional" source code management system like CVS would be to do one change set per class. Since we are talking about Smalltalk code here, I must admit that that feels like a wierd conclusion to have reached--file-per-class: how C++/braindead is that?!

So I am wondering what your plan/vision for DVS is going forward. Nosing around in the source for DVS I notice that you've got a DirectoryPackageLoader and Dumper; though they are not hooked up to anything and the Dumper doesn't look like it is fully functional. Is this something you are working on or was this a dead end?

I really miss having a source code manager when I'm coding in Squeak. Just this week I threw away a whole day's worth of work just because I had no decent way to back out of a rathole I'd gone down. I think it keeps from doing as much coding in Squeak as I might otherwise, too.

david

--
David Farber
dfarber@numenor.com