The CRLF and paths bit is most probably due to the fact that I do my diff/merge/dev work on Win32/64 boxes mostly - that's where all my toolkit sits anyway; hadn't realized your patch was that picky. When I do it on a *nix box, I always run 'patch -l' which doesn't complain; when code looks a real mess, there's always uncrustify - the savior for supplicants of disparate coding standards.
Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. Hm. So this means I'd better do a double-buffered process there: kick the edits over to the UNIX box into the fresh OpenSSL tree, erase the comments and pull a diff for those. Post, rinse (refresh OpenSSL base tree) & repeat. On Wed, May 26, 2010 at 8:28 PM, Stephen Henson via RT <[email protected]>wrote: > This (and several other) patches contain DOS CRLF EOLs and file names > (backslash separator). What are those [i_a] bits in comments as well? > > It would be appreciated if they had Unix LF EOL and path names so > patches can be applied cleanly without having to be manually edited. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 --------------------------------------------------The CRLF and paths bit is most probably due to the fact that I do my diff/merge/dev work on Win32/64 boxes mostly - that's where all my toolkit sits anyway; hadn't realized your patch was that picky. When I do it on a *nix box, I always run 'patch -l' which doesn't complain; when code looks a real mess, there's always uncrustify - the savior for supplicants of disparate coding standards.
Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you.
Hm. So this means I'd better do a double-buffered process there: kick the edits over to the UNIX box into the fresh OpenSSL tree, erase the comments and pull a diff for those. Post, rinse (refresh OpenSSL base tree) & repeat.
On Wed, May 26, 2010 at 8:28 PM, Stephen Henson via RT <[email protected]> wrote:
This (and several other) patches contain DOS CRLF EOLs and file names
(backslash separator). What are those [i_a] bits in comments as well?
It would be appreciated if they had Unix LF EOL and path names so
patches can be applied cleanly without having to be manually edited.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------
