bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Is there really any interest in a patch to allow cvs 1.11.6 to run o


From: Kelly F. Hickel
Subject: RE: Is there really any interest in a patch to allow cvs 1.11.6 to run on HP/COMPAQ/TANDEM/NSK or am I just wasting my time.....
Date: Fri, 26 Sep 2003 16:10:51 -0500

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
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.


***************
*** 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;
      }

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677
address@hidden


> -----Original Message-----
> From: Mark D. Baushke [mailto:address@hidden
> Sent: Friday, September 26, 2003 3:36 PM
> To: Kelly F. Hickel
> Cc: address@hidden
> Subject: Re: Is there really any interest in a patch to allow cvs
1.11.6
> to run on HP/COMPAQ/TANDEM/NSK or am I just wasting my time.....
> 
> Kelly F. Hickel <address@hidden> writes:
> 
> > I've submitted patches for earlier (1.10.7) versions of cvs to
> > allow it to build and work (at least in client mode) on HP (or
Compaq or
> > Tandem take your pick) NSK in the OSS environment (none of which may
> mean
> > anything to you, but it's a big, ugly transaction processing system)
in
> > the past, but none of them seem to have found their way to
acceptance.
> > I'm considering porting the latest stable (1.11.6, right?) source to
> this
> > platform, but unless there's some hope of getting the changes in,
I'll
> > probably give it a miss, at least for awhile.
> >
> > So, what's the story?  Any interest in a port for a weird
> > system that most people won't use, or not?  The bulk of the changes
have
> > to do with detecting the OS and dealing with the charming "feature"
that
> > read/write don't (seem) to work with buffers > 52k bytes...........
> 
> Ouch. That sounds nasty.
> 
> To be honest, if the patches are at all invasive, you will have a
higher
> likely hood of getting such patches into the 1.12.x "feature" main
> trunk than into the stable 1.11.x branch.
> 
> That said, I'll let Larry and Derek comment on how and into which
> branches support for new platforms gets added. One problem being
> that it may be very easy to break such a platform if none of us
> has any way to test it.
> 
>       -- Mark





reply via email to

[Prev in Thread] Current Thread [Next in Thread]