In (our-ref) D131514, one of our users reported that bk changes was only displaying the most recent month or so’s changesets in our “misc” repository, unlike cd && bk changes. I see from the bk source that passing on the command line makes bk use a bkd, even if it’s a local path. I couldn’t reproduce the issue on bk’s own repository until I accidentally created a long dspec. Watch it fail with a line 1022 characters long:
martind@swiftboat:~/download/bk/dev$ bk changes -q -n -r+ -d"$(ruby -we 'puts("." * 1021)')" | wc -l
1
martind@swiftboat:~/download/bk/dev$ bk changes -q -n -r+ -d"$(ruby -we 'puts("." * 1022)')" | wc -l
1
martind@swiftboat:~/download/bk/dev$ bk changes -q -n -r+ -d"$(ruby -we 'puts("." * 1021)')" . | wc -l
1
martind@swiftboat:~/download/bk/dev$ bk changes -q -n -r+ -d"$(ruby -we 'puts("." * 1022)')" . | wc -l
0
martind@swiftboat:~/download/bk/dev$
Comments in most of our repositories seem to have been involuntarily wrapped, I assume by some bk command, as we’re clearly in full infinite monkey ^W^W Tolstoy mode, at 1020 characters (bk changes indents them with two spaces by default):
martind@swiftboat:~/work/cannon3$ bk changes | wc -L
1022
martind@swiftboat:~/work/cannon3$
martind@swiftboat:~/work/misc$ bk changes | wc -L
1022
martind@swiftboat:~/work/misc$
We do, though, have at least one line in a check-in comment that’s getting on for a KiB and a half:
martind@swiftboat:~/work/cornet3$ bk changes | wc -L
1363
martind@swiftboat:~/work/cornet3$
This seems to fix my above test cases:
--- 1.207/src/changes.c 2016-09-30 07:58:23 -07:00 +++ edited/src/changes.c 2017-08-22 17:06:02 -07:00 @@ -1720,7 +1720,7 @@ changes_part1 changes_part1(remote *r, char **av, char *key_list) { int flags, fd, rc, rcsets = 0, rtags = 0; - char buf[MAXPATH]; + char buf[MAXLINE]; if (bkd_connect(r, 0)) return (-1); if (send_part1_msg(r, av)) return (-1);
That clearly does nothing about the distressing lack of error reporting, should the new limit prove to be inadequate too, but perhaps that’s a non-issue.