Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Nov 1997 09:10:39 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Richard Wackerbarth <rkw@dataplex.net>
Cc:        Brian Somers <brian@awfulhak.org>, Annelise Anderson <andrsn@andrsn.stanford.edu>, freebsd-stable@FreeBSD.ORG
Subject:   Re: Version Resolution?
Message-ID:  <199711201610.JAA10077@mt.sri.com>
In-Reply-To: <l03110700b0995d120c56@[208.2.87.4]>
References:  <199711192205.PAA06912@mt.sri.com> <199711200032.AAA12288@awfulhak.demon.co.uk> <l03110700b0995d120c56@[208.2.87.4]>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711201610.JAA10077>