[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn patch" and the TAB character

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Wed, 18 Dec 2019 16:24:06 -0500

Brane, Stefan, Daniel, Nathan:

Thank you for the discussion - it filled in history that I could not find.
I understand the issues now. Cheers!

Happy Holidays!

Doug

On Tue, Dec 17, 2019 at 9:42 AM Branko Čibej <brane_at_apache.org> wrote:

> On 17.12.2019 14:58, Stefan Sperling wrote:
> > On Tue, Dec 17, 2019 at 08:33:09AM -0500, Doug Robinson wrote:
> >>> And of course, both the
> >>> filename and the label (= the part after the tab character) may
> contain an
> >>> arbitrary number of spaces.
> >> The problem is parsing the line into proper tokens when every character
> out
> >> there can be part of the file name. There must be a structure to the
> field
> >> or parsing is not really parsing anymore.
> > The output of 'svn diff' was not designed with 'svn patch' in mind.
> > The diff command preceded the patch command by many years.
> >
> > I still believe that making --patch-compatible produce filenames without
> > any trailing annotations in the output of 'svn diff' is the best answer.
>
>
> Agreed. Plain-vanilla BSD patch should be able to apply such patches, as
> should 'svn patch'.
>
>
> > This whole discussion started off with the problem statement that the
> > --patch-compatible option produces a diff which cannot be applied after
> > tabs are replaced with spaces.
> >
> > This filename parsing problem isn't limited to 'svn patch'. Other patch
> > implementations might run into the same problem. The way 'svn patch'
> finds
> > the filename is based on Larry Wall's original patch program.
>
> Precisely. That TAB *is* the canonical delimiter. The (implicit)
> specification is decades old, and it would be an error to try to
> second-guess it at this point.
>
> Designing a stricter universal format for transmitting contextual
> changes is a different matter entirely, one that we tried to tackle in
> the past and failed; other version control systems tried and failed,
> too. It would be a nice thing to have, but it's hardly something this
> community can do in isolation.
>
> > Generally, patches being mangled in transit is a notorious problem
> especially
> > with web-based email. It's not really a safe format for this purpose. If
> patches
> > get changed in transit in any way there is no guarantee they will apply
> cleanly.
> > That's not a new problem, it's a long-standing issue. And it's not
> SVN-specific.
> > There is already a way to transfer changes without such problems: svn
> commit
>
> And note that the tabs-to-spaces headache doesn't stop with parsing the
> filename out of the header, it affects the filename itself. I can put
> tabs in a filename on most Unix filesystems ... that would probably
> break even the original patch tool.
>
> -- Brane
>

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson_at_wandisco.com
-- 
* <http://wandisco.com/>*
**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*
 
<https://www.wandisco.com/liveanalytics>
THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*
If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.
Received on 2019-12-18 22:24:28 CET

This is an archived mail posted to the Subversion Dev mailing list.