Ideas, Experiences required for changes managements

Avi Bryant avi at beta4.com
Mon Mar 31 16:46:42 UTC 2003


On Mon, 31 Mar 2003, Ned Konz wrote:

> > category/classname/classdef
> > category/classname/methodcategory/method1
> > category/classname/methodcategory/method2
> > etc.
> >
> > And filed-in in the same manner, wouldn't source control systems be
> > able to handle that better?  I know this probably wouldn't work
> > well in CVS (since it doesn't support renames), but with Subversion
> > (successor to CVS), BitKeeper, or a number of more recent CMS
> > systems, it might work better.  Or not?
>
> This is/was done by at least one such system (I forget the name,
> though).

CVSTProj, although it used one file per class, not one per method.  What I
dislike about this approach is that it adds a fair amount of overhead to
adding/removing/renaming a class - in at least Subversion and CVS (I've
never used BitKeeper), you have to manually notify the versioning system
whenever you do one of those things.  The only real advantage you get in
return is that it's easier to browse the repository - but who wants to
look at filed out code anyway? Better to browse it in the image.

Using one file per method certainly eliminates all spurious conflicts, and
at one point I did have a file out mode for DVS that did this, but of
course this becomes completely infeasible if you have to manually do "cvs
add" and "cvs remove" all the time.  If anyone knows of a simple tool for
CVS that will automatically sync the repository with a working copy in
that way, let me know...

As I said earlier, however, the current file out format DVS uses has been
tweaked to the point that it's rare to see a conflict unless you radically
restructure the class hierarchy (and even then you only get conflicts in
the class def'n section of the file).

Avi



More information about the Squeak-dev mailing list