Date: Fri, 31 Jan 1997 11:20:48 +0100 (MET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: kpneal@pobox.com (Kevin P. Neal) Cc: hackers@freebsd.org Subject: Re: Source code commits Message-ID: <199701311020.LAA26256@ocean.campus.luth.se> In-Reply-To: <1.5.4.32.19970131030617.00922bc8@mindspring.com> from "Kevin P. Neal" at "Jan 30, 97 10:06:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Kevin P. Neal: > At 01:26 AM 1/30/97 -0700, Nate Williams wrote: > >> I suggested a sort of "write-through" validation/submission system for > >> the CVS tree a year ago, where anyone could "commit" to the source > >> tree but for those people who weren't actually authorized to commit > >> directly, what would happen instead is that the diffs would be > >> automagically sent to the person or persons actually responsible for > >> the code in question, and they would review and optionally commit it. > > > >Aieee, why go for trivial solutions when we can do something much more > >useful (and difficult). > > > >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. Then you could start building a project, using old classes that had some nice basic functionality you need, like a mutex wrapper, or so. Imagine if you could do something like this to create a new project: me@my> cvs new MyNewProject me@my> cd MyNewProject me@my> mkdir thread_sync me@my> cd thread_sync me@my> cvs include mutexwrapper.cc me@my> emacs semaphorewrapper.cc me@my> cvs add semaphorewrapper.cc me@my> ls mutexwrapper.cc semaphorewrapper.cc me@my> cd .. me@my> vi Makfile me@my> cvs add -private Makefile me@my> ls $CVSROOT/PUBLIC/ mutexwrapper.cc semaphorewrapper.cc me@my> ls $CVSROOT/MyNewProject PUBLIC_INCLUDES Makefile me@my> echo "YES! HURRAY!" etc... 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. I just had to get that out of my system :-) It's THE greatest flaw with CVS as it is today, IMHO. /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701311020.LAA26256>