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

Re: 'patch' behaviors

From: Karl Fogel <kfogel_at_collab.net>
Date: 2001-06-22 18:34:54 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> By definition, they do (unless they're zero-length). I thought I was
> pretty clear that I was using "text" as a technical term, not just in
> the sense of "something you can look at with cat without making your
> xterm go all wonky." Lots of Unix utilities won't work especially
> well on files which don't match this technical definition of "text."
> Try running a file with no trailing newline through the Solaris or
> IRIX "sed" or "nl" and you'll see abnormalities, just to pick two
> operating systems and commands out of a hat. "patch" on FreeBSD is
> merely the tip of the iceberg.

You were being clear, but the technical definition of "text files"
doesn't matter here. The point is that people make files all the time
that contain plaintext (according to the naive definition), and expect
them to be treated as plaintext by their tools -- in other words, they
expect merging to work, whether or not they have a final newline in
the file. Such files work with CVS, and they must work with

> One of the attractions of the GNU versions of Unix tools is that they
> generally work on arbitrary binary files to the greatest extent
> possible. Which is great, but we can't rely on this feature in
> Subversion unless we're actually bringing in that code (which we can't
> do unless it becomes LGPL'd, another side of this discussion).

Not true. There are other solutions besides bringing in the code:

  - We can require GNU patch to be present on the system.
    Inconvenient, perhaps, but unambiguous and auto-detectable.

  - We can write workaround code in Subversion. You know, detect the
    absence of a final newline, remember it, re-compensate after the
    merge, that sort of thing.

> I don't think there's any disagreement about what we should do; I just
> want to make sure people are perceiving the situation properly.

Not sure what you mean by "properly", but I hope my comments above
make sense. :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:32 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.