From owner-freebsd-stable Thu Nov 20 08:10:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14272 for stable-outgoing; Thu, 20 Nov 1997 08:10:54 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA14266 for ; Thu, 20 Nov 1997 08:10:51 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA18942; Thu, 20 Nov 1997 09:10:47 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA10077; Thu, 20 Nov 1997 09:10:39 -0700 Date: Thu, 20 Nov 1997 09:10:39 -0700 Message-Id: <199711201610.JAA10077@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Wackerbarth Cc: Brian Somers , Annelise Anderson , freebsd-stable@FreeBSD.ORG Subject: Re: Version Resolution? In-Reply-To: References: <199711192205.PAA06912@mt.sri.com> <199711200032.AAA12288@awfulhak.demon.co.uk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For individuals who are not DIRECTLY accessing the master tree (which > is MOST of the world), the technique works. There are two conditions > that my code does not address. This is where Nate and I seem to > differ. In my extended discussions with him BEFORE I wrote any of > the code, we discussed these issues. I thought that he had agreed > that they fell in the "nice, but not essential" category We discussed the requirements, and I we agreed that we weren't sure if it was required. But, upon further thought and with a couple different (easily capable) possibilities, I showed that your solution was inadequate and would cause essentially 'corrupted' RCS files when new tags were made, which would cause both CVSup and CTM to either blow chunks or distribute corrupt RCS files. This is unacceptable. , and, as > such, could be deferred to a later revision. However, since I > finished the present version of the code only shortly before 2.2.5 > was to be released, it was agreed that the time was not appropriate > to commit the code at that time. Since, in Nate's opinion, there > was time to do more, he unilaterally raised the requirements. Unilaterally raised the requirements. Wow, I didn't realize I could something that sounds so, so, so cool and hip. :) > Since I have not "solved" these additional problems, he seems to > feel that my submission is unacceptable. Because of RCS file corruption, yes. > The first involves the automatic recognition of new BRANCHES in the > tree. This feature can be added. IMHO, this can aloso be handled > manually for the present time. I have not seen more than about one > or two new branches added in the same year. It happens more often than that. Heck, Julian has plans to add a new one in the near future. In any case, even if it happened once/year, if you corrupt the 'template' RCS file you risk breaking someone's tree or causing more questions than the solution fixes. This is unacceptable. I talked with John about the 'normal' RCS files that would be generated, and he wasn't sure what CVSup would do with them, let alone an RCS file where branches bounce around whenever they're created. The problems do NOT outweigh the solution, and that is why I 'unilaterally raised the requirements'. That is in my authority to do so, since *I'm* the one taking the heat for committing the code and breaking the FreeBSD and SRI CVS trees. As an engineer, if I feel a solution is inadequate, it is well within my rights to reject it on technical grounds, which I did. And, you can argue all day long about 'changing the rules', but bogus code is bogus code, and I'm not going to break the tree to make you have a warm-fuzzy feeling inside. Nate