moving patches between unix and windows?

[Andrew McIntyre <fu...@nonintuitive.com>]

Hi all,

I've been working with different patches and trying to move patches 
back and forth between different Unix and Windows machines for testing 
and it's a bit of a pain. Going either way, line-ending conversion is 
necessary.

When going from Unix to Windows, it requires changing the LFs to CRLFs 
by opening in wordpad (but not notepad) and saving to change the line 
endings or doing "perl -p -e 's/\r/\n\r/g'  < in.patch | patch".

When going from Windows to Unix, you have to convert the line endings 
with "perl -p -e 's/\n/\r\n/g' < in.patch | patch -p0". This would seem 
to be adding another carriage return to the CRLF, but that's what works 
for me. And sometimes I can't get it to work at all, and it seems to 
depend on how forgiving that particular machine's patch command can be. 
  (Unix here refers to Linux, Mac OS X, or Solaris, I get pretty much 
the same results on any platform)

Applying patches from mail is usually not a problem, but only because 
my native mail programs converts the line endings for me. However, some 
mail programs word wrap the patch and truncate the lines where patch 
does not expect them to be broken, thus causing patch to choke at the 
first place where word wrap occurs. This just may be user error on my 
part, or maybe the mail program isn't paying enough attention to the 
headers.

So, question is: is there a way to get around having to convert the 
line endings? Some magic option to patch to tell it to ignore the line 
endings in the patch and affected files? Or is this just the pain of 
working in a mixed Windows/Unix environment?

Thanks,
andrew

Re: moving patches between unix and windows?

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonas S Karlsson wrote:

>>Your recipe for adding new text files should be:
>>$ svn add foo
>>$ svn propset svn:eol-style native foo

> This probably means we need to do this for all non-binary files.

This does seem to solve the patch problems I was seeing between windows
and linux.

I will modify all the text files checked in, all .txt, .java,
.properties and .xml files with

svn propset svn:eol-style native

I assume lazy approval for this.

If others can hold off submitting patches until this is done, that would
be good.

Dan.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBUwkcIv0S4qsbfuQRAhdhAJ4zGAqluPKL1o7Nem9L8ot7dXFlhQCgt/yf
O6RLCaTzxVJ4JtxgEDL/RcI=
=khh6
-----END PGP SIGNATURE-----

Re: moving patches between unix and windows?

[Jonas S Karlsson <js...@yesco.org>]

This is a followup regarding line-ending conversion problems reported
by Andrew during application of patches, the solutions seems to be
setting properties correctly as indicated by links in this text...

Andrew wrote:
>I've been working with different patches and trying to move patches 
>back and forth between different Unix and Windows machines for testing 
>and it's a bit of a pain. Going either way, line-ending conversion is 
>necessary.

Me myself wrote:
> I don't think that unixtools expect the source to contain CRLF
> which I believe all of Derby code does. This often shows up as
> "extra" ^M at the end of each line in emacs for example...
>
> It seems that patch does it's best to ignore CRLF in the diff input
> that it takes, but maybe it doesn't handle it in the actual source.

The solution seems to be indicated by using propset as described at
this swedish website:

http://www.contactor.se/~dast/svn/archive-2002-11/0908.shtml
> All right, this is a pretty standard problem if you have files with
> mixed line endings. To answer your original question: no, diff/diff3 do
> not, in general, handle this situation graceully.
> 
> Now, please explain why you don't set the property svn:eol-style to
> 'native' on text files? If you do that, Subversion will automagically
> convert the end-of-line markers to whatever is appropriate to the client
> system, and leave them in a canonical form in the repository.
> 
> Your recipe for adding new text files should be:
> $ svn add foo
> $ svn propset svn:eol-style native foo
> $ svn commit ...
> 
> You can do the same (without the add) to fix your local files, but you
> should convert all line endings to the local style first.

See also part 5 of svn tips:

  http://www.onlamp.com/pub/a/onlamp/2004/08/19/subversiontips.html

There it is also indicated that one can set this as an automatic
property by using the configuration:

  http://svnbook.red-bean.com/svnbook-1.0/ch07s02.html#svn-ch-7-sect-2.4

This probably means we need to do this for all non-binary files.

/Jonas

Re: moving patches between unix and windows?

[Jonas S Karlsson <js...@yesco.org>]

Andrew wrote:
>I've been working with different patches and trying to move patches 
>back and forth between different Unix and Windows machines for testing 
>and it's a bit of a pain. Going either way, line-ending conversion is 
>necessary.

"man patch" says:

 patch  tries to skip any leading garbage, apply the diff, and then skip
 any trailing garbage.  Thus you could feed an article or  message  con-
 taining  a  diff  listing  to patch, and it should work.  If the entire
 diff is indented by a consistent amount, or if a context diff  contains
 lines ending in CRLF or is encapsulated one or more times by prepending
 "- " to lines starting with "-" as specified by Internet RFC 934,  this
 is  taken  into  account.   After  removing indenting or encapsulation,
 lines beginning with # are ignored, as they are considered to  be  com-
 ments.

I don't think that unixtools expect the source to contain CRLF
which I believe all of Derby code does. This often shows up as
"extra" ^M at the end of each line in emacs for example...

It seems that patch does it's best to ignore CRLF in the diff input
that it takes, but maybe it doesn't handle it in the actual source.

/Jonas