RE: Is there really any interest in a patch to allow cvs 1.11.6torun on HP/COMPAQ/TANDEM/NSK or am I just wasting my time.....

[Kelly F. Hickel]

> -----Original Message-----
> From: Paul Edwards [mailto:kerravon@nosppaam.w3.to]
> Sent: Friday, September 26, 2003 5:51 PM
> To: bug-cvs@gnu.org
> Subject: Re: Is there really any interest in a patch to allow cvs
> 1.11.6torun on HP/COMPAQ/TANDEM/NSK or am I just wasting my time.....
> 
> "Kelly F. Hickel" <kfh@mqsoftware.com> wrote in message
> news:mailman.784.1064610662.21628.bug-cvs@gnu.org...
> > Here's an example of one such change (most are limited to client.c),
> > there might be a cleaner way to do it.  In fact, the comment at the
top
> > of the area indicates that at least one person thought that it would
be
> > good to go in this direction anyway.  If there were a consensus of
"the
> > right way" to do this, I'd be interesting in at least helping
implement
> > that, even if it meant more work for me.
> 
> > I realize more people are interested in the dev version, but I
really
> 
> I don't know how you know that.

I should have said "I realize that those people who decide which patches
to accept diffs for the dev version", that info comes from the HACKING
file, and from this list.

> 
> > need to be using a stable version.   I can whack the changes into my
> > copy of the stable and help on the dev changes, but I'd *REALLY*
want to
> > know that the changes were going to be accepted before I went to
that
> > extra length.
> 
> Personally, I think that this should be considered to be a fix to a
> bug that is preventing CVS from working on Tandem etc, and

I can't really disagree.

> should go into the stable release.  And FYI, about 3 months ago
> I was talking to someone, who was considering going to work
> for a company running Tandem NSK to do source control, and
> I told him to install CVS there, and that if he didn't want the
> job, I'd take it.  He didn't take the job, and I may contact the
> company in January to see if the position is still available.  So
> can you have it ready by then?

That should be no problem, I don't think it should take more than a week
or two, even with my current work load.

> 
> 
> ***************
> *** 4912,4922 ****
>          Instead of this we should just be reading a block of
>          data (e.g. 8192 bytes), writing it to the network, and
>          so on until EOF.  */
>       while ((len = read (fd, bufp, (buf + sb.st_size) - bufp)) >
> 0)
>           bufp += len;
> !
>       if (len < 0)
> !         error (1, errno, "reading %s", short_pathname);
> 
>       newsize = bufp - buf;
>   }
> --- 4952,4974 ----
>          Instead of this we should just be reading a block of
>          data (e.g. 8192 bytes), writing it to the network, and
>          so on until EOF.  */
> +
> + #ifdef WRITE_CANT_HANDLE_LARGE_BUF
> +       int to_read=(buf + sb.st_size) - bufp;
> +       if(to_read > SINGLE_WRITE_SIZE)
> +         to_read = SINGLE_WRITE_SIZE;
> +     while ((len = read (fd, bufp, to_read)) > 0) {
> +         bufp += len;
> +         to_read=(buf + sb.st_size) - bufp;
> +         if(to_read > SINGLE_WRITE_SIZE)
> +           to_read = SINGLE_WRITE_SIZE;
> +       }
> + #else
>       while ((len = read (fd, bufp, (buf + sb.st_size) - bufp)) >
> 0)
>           bufp += len;
> ! #endif
>       if (len < 0)
> !         error (1, errno, "reading #7 %s", short_pathname);
> 
>       newsize = bufp - buf;
>       }
> 
> Yuck.  I think this "reading #7" is overkill.  And I would
> create a function called "saferead" or something like that,
> which replaces read, so that the only change you see to
> client.c is read being replaced by saferead.
> 
> And then you create a saferead that has all that crap in it.
> Maybe in subr.c?
> 
> And in actual fact, you can even put a #define read saferead
> in a header file, so you don't need to touch client.c at all.

The reading #7 is from trying to find out which of the N "failed reading
foo.c" errors was actually hit, and wouldn't have been part of the
patch.  Yep, the code above is ugly, but it was done before the full
scope of the problem had hit me, when I was just trying to get something
to work.  It actually affects both reads and writes on both files and
sockets....

Something like safe read/rite would be OK, I was wondering if that was
something people wanted to see on more than just the NSK system (because
of the comment that io should be done in 8k chunks), in which case a
different implementation would be in order.

Note that I've never run the tests, I've fixed things as I've come to
them.  Also, I have no interest in running a server on NSK.  Now, if I
thought someone else would actually use the stuff, I'd be more inclined
to do the full test suite, etc......

-Kelly

> 
> But note, it is not me who decides what gets accepted, so
> don't do that work based on my say-so.
> 
> On the other hand, your changes above will make it easier
> for you to upgrade to a new version of CVS in the future,
> because your changes are purely additional code, you're
> not changing other code that is subject to change.
> 
> BFN.  Paul.
> 
> 
> _______________________________________________
> Bug-cvs mailing list
> Bug-cvs@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-cvs