From owner-freebsd-hackers Fri Jan 31 09:28:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02340 for hackers-outgoing; Fri, 31 Jan 1997 09:28:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02334 for ; Fri, 31 Jan 1997 09:28:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02984; Fri, 31 Jan 1997 10:25:38 -0700 From: Terry Lambert Message-Id: <199701311725.KAA02984@phaeton.artisoft.com> Subject: Re: Source code commits To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Fri, 31 Jan 1997 10:25:38 -0700 (MST) Cc: kpneal@pobox.com, hackers@FreeBSD.ORG In-Reply-To: <199701311020.LAA26256@ocean.campus.luth.se> from "Mikael Karpberg" at Jan 31, 97 11:20:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >I think it would be easier to rewrite CVS from scratch. :) > > > > Starting with RCS. A nice library with a well defined interface. > > Then CVS can be put on top of that. > > > > This is actually on my todo list. Above it, however, is getting a stable > > machine to do the coding on. > > That sounds great! If you do, however, PLEASE fix the fundamental flaw in > cvs: It treats projects, not files. *sigh* > > This is VERY annoying when using C++, wher eyou have one class per file, > and you try to do code reuse. > > It would be SO nice if you just checked all the files in a "global heap", > (unless you specifically said it was to be a project specific file) and > what the "project" normally was was just a file looking something like > the current ".../CVS/Entries" files. Ugh. The "global heap" idea in PVCS and in DEC's VCS both suffer from not letting you have duplicate file names in code branches. This is very bad if you want to provide an encapsulated inplementation class for an interface class for something like, oh, say, y.tab.c, y.code.c, y.tab.h, and lex.yy.c. For instance, if you have an interface class "automaton" or "character parser" that encapsulated the lex/yacc relationship and you had multiple implementation classed for that interface. > Then, if I made a bugfix in my mutexwrapper, it would automatically spread > to all my other projects using it, and they could in turn include the > semaphore wrapper from this project and start using that. Maybe my example > above is wrong. Maybe it should be default private, and have a -public > switch. Or maybe have both switches and a .cvsrc option to set the default. > It would greatly simplyfy code reuse, and would be very useful, at least > for me, trying to track bugfixes across projects at work, and at home. > Maybe you should also be able to include a project specific file in another > project, if two of your projects need an extra funktion in the mutexwrapper > that you don't want to add for all other projects. Hmm... Almost, for C++, you want to implement at the interface level and include the interface definitions in your consumer code, but leave the implementation class as common code associated through the abstract virtual base class... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.