cvsclient: handle files which lack a trailing newline

CVS uses \n as a protocol message separator, which forces us to read protocol message line-by-line. File content sent by the server has a length known and is transmitted in bytes. The server appends a final "ok\n" message (or perhaps an error message) when it is done sending file contents.

Properly handle the case where this final message gets buffered along with file contents and is not delimited from file contents by \n because the file lacks a trailing newline. Previously, the final protocol message ended up being written out to file contents in this case.

Found while testing ingestion of the GNU dino CVS repository from cvs.savannah.gnu.org/sources/dino.

Related to #3691

---

Migrated from D6558 (view on Phabricator)

Build is green

Patch application report for D6558 (id=23832)

Rebasing onto 7f761b85...

Current branch diff-target is up to date.

Changes applied before test

commit d3b3344bc26d90acb081fe827aed60257d931cfe
Author: Stefan Sperling <stsp@stsp.name>
Date:   Wed Oct 27 11:55:04 2021 +0200

    cvsclient: handle files which lack a trailing newline
    
    CVS uses \n as a protocol message separator, which forces us
    to read protocol message line-by-line. File content sent by
    the server has a length known and is transmitted in bytes.
    The server appends a final "ok\n" message (or perhaps an error
    message) when it is done sending file contents.
    
    Properly handle the case where this final message gets buffered
    along with file contents and is not delimited from file contents
    by \n because the file lacks a trailing newline. Previously, the
    final protocol message ended up being written out to file contents
    in this case.
    
    Found while testing ingestion of the GNU dino CVS repository from
    cvs.savannah.gnu.org/sources/dino.

See https://jenkins.softwareheritage.org/job/DLDCVS/job/tests-on-diff/33/ for more details.

Could you add a test?

! In !14 (closed), @vlorentz wrote: Could you add a test?

Yes, I have a test in progress.

It would be easier to add the test later, because the test will require other outstanding pserver protocol fixes to be merged as well. Otherwise the pserver protocol handling is too broken and triggers unrelated failures.

I could add the test stacked on top of all required fixes now, but perhaps we can simply do this once all the fixes are merged?

! In !14 (closed), @stsp wrote: perhaps we can simply do this once all the fixes are merged?

Sure!

Merge request was accepted

approved this merge request

Merge request was merged

closed