Subject: Re: CVSup collections for a NetBSD CVS tree
To: None <>
From: Jaromir Dolecek <>
List: current-users
Date: 04/29/1999 12:13:54
Greg A. Woods wrote:
> > If we need a good (and portable) tool, we should consider creating one 
> > that matches other goals of NetBSD.
> I personally wouldn't even dream of trying to re-invent or even
> re-implement CVSup, not even if I had all the spare time it would take
> to do so.  It does what it does very well and it's already freely
> available and well maintained.  I'd much rather invent a better CVS! ;-)

Yeah, THAT would be THE Right Thing To Do (TM).

If CVSup knows all the dirty details of RCS and CVS and in function
is something like anoncvs (though more efficient), I don't quite understand
why it was not written as enhancement of anoncvs and is maintained separately.

And more -- the person who wrote CVSup wrote it in such a obscure and
dying language as the Modula-3 is. Really unfortunate decision. They
can't even share any code with CVS, they HAVE to rewrite the whole thing.

Such approach makes me scream ;-)

Somebody mentioned porting M3 to (n-2) NetBSD architectures. Well, it's
doable, but M3-based CVSup has some more disadvantages:
1) not many programmers are common with M3 (the amount of such
	programmers is IMHO compared with COBOL programmers) -- 
	modifying CVSup to better fit NetBSD environment and
	bug fixing would be quite hard or near to impossible
2) need to install (potentially huge) environment for M3 for just
	ONE application (not such a big problem with binary packages,
	but still)
3) M3 folks have to re-do all the hard work of gcc/egcs folks
	of optimizing compiler for all the archs/oses it might run on;
	if we would decide to use it for tool NetBSD relies on, we
	would have to actually SUPPORT it on our side -- any voluteers
	willing to do it ?

Is there any great demand for M3 under all the NetBSD architectures ?
If not, porting it just for one application seems to me like enormous
wasting of valueable human resources. Rewriting the application in C
seems like much better idea -- and merging to cvs is the way to go.

NOT porting M3 to all NetBSD archs or CVSup to C is not an option.
I would be really sad, if NetBSD way of thinking would change to:
"Well, we distribute our source tree via highly efficient and
fast CVSup service. Enjoy."
"Ah, forgot to mention. You have to have i386 or alpha to use it."

One reason I love NetBSD is we are treating all the archs equal -- I can
choose whatever hardware I happen to have and am still able to work
more-or-less the same way.
Jaromir Dolecek <>
"The only way how to get rid temptation is to yield to it." -- Oscar Wilde