Date: Tue, 17 Jan 1995 18:31:27 +0000 (GMT) From: Paul Richards <paul@isl.cf.ac.uk> To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: pst@shockwave.com, ache@astral.msk.su, CVS-commiters@freefall.cdrom.com, cvs-CVSROOT@freefall.cdrom.com Subject: Re: cvs commit: CVSROOT modules Message-ID: <199501171831.SAA02903@isl.cf.ac.uk> In-Reply-To: <9501170316.AA23492@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jan 16, 95 10:16:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Garrett Wollman who said > > I don't see anything bad about this. Once we've released 2.2, there > is no reason to keep around old, bogus versions of software that were > used two releases previously and isn't maintained (or indeed > maintainable, which was PST's principal---and laudable---contribution). I disagree. I think it's necessary for us to be able to retrieve any previous revision. There have been a number of times when I've checked out old versions of code because they worked and newer code failed in some way. > > > There'd be no problem getting a 2.0R snapshot with the way I did it. The > > way you're doing it prevents this though. > > The ``way you did it'' perverts the design of CVS in a way that makes > maintenance almost impossible. (Witness the fact that a new version > had been out for quite a while now before someone actually sat down > and did the work that CVS is designed to do automatically.) The "way I did it" is wrong, I agree, but the real problem is that the cvs tree was not used properly initially so we have to find a way now to "fix" the problem so that cvs can be used as it should be in the future. > > We > > shouldn't use cvs to do things like run parallel development > > This, however, is quite true. But the particular example given here > is a special case in the extreme. This is all very interesting but it's not solving the problem. I think we should adopt Rod's idea, start a new directory /usr/src/gpl and do all the fresh imports into that and this time put them properly on vendor branches so that future upgrades become fairly painless. I'm really not going to be happy if we blindly carry on adding more baggage to the repository in a way that can't be filtered out when I sup. -- Paul Richards, FreeBSD core team member. Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff. Internet: paul@FreeBSD.org, JANET(UK): RICHARDSDP@CARDIFF.AC.UK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501171831.SAA02903>