Re: "svn patch" and the TAB character

Doug Robinson wrote on Mon, Dec 16, 2019 at 11:13:25 -0500:
> So the two file names, differing only by a TAB in the "right place" will
> currently have completely different behaviors:
>
> My File NameSPACE(Revision 12)
> My File NameTAB(Revision 12)
>
> I see no point in maintaining that the "TAB" is critically significant and
> different from the "SPACE". The difference is easier parsing vs. 1 visually
> indistinguishable use case (depending on what tool you are using to view the
> diff file).
>
> And the "sequence of SPACE" instead of just a single "SPACE" falls into the
> same visually indistinguishable category. So keep the parsing simple and
> just declare file names with "SP/TAB(Revision #)" at the end to not be
> supported.

You can't assume the string after the tab will be "(revision %ld)".

First of all, as I already pointed out, that string is translatable. Second of
all, we also have to support patches generated by third-party tools, which may
contain arbitrary text after the tab character. And of course, both the
filename and the label (= the part after the tab character) may contain an
arbitrary number of spaces.

Please propose an algorithm for parsing a filename out of a diff header line
(a '---' line or a '+++' line) that doesn't contain tabs, under these conditions.
(We don't have to fix _all_ cases, but fixing the bug just for English speakers
isn't going to fly.)

---
I suppose that simply trying to repeatedly s/\s+\S+$// might work well enough?  That is:
    data = line[len('--- '):].rstrip('\n')
    need_confirmation = False
    while len(data) > 0:
        if exists(data):
            break
        else:
            data =~ s/\s+\S+$//;
        need_confirmation = True
    else:
        raise Exception("{!r} does not exist".format(line[4:]))
    if need_confirmation:
        prompt_for_confirmation(data)