Re: Creating a UNIX module

Arthur Barrett wrote:

> What Torsten has written is correct, however let me make a 'bigger
> picture' point. 
> 
> The BEST way to work is to let all text files be text files - that
> means that on windows a bash script has cr/lf line endings and on
> unix it has lf line endings.  eg: a cobol file on as/400 will be
> fixed length records, on windows cr/lf delimited text file and lf
> delimited text on unix. 

Sometimes that is "BEST", other times something else may be best.

I work in an environment where bash scripts are never run under Windows;
the only way bash scripts are run is under Linux. We also like to
compile local changes under both Windows and Linux before checking in.
This means that I have e.g. a sandbox on my Windows system that is
shared and accessed from my Linux system. The Linux the build uses the
bash scripts in the (Windows) sandbox, which requires them to have Unix
line endings.

We could of course commit to a branch on Windows, then update to that
branch on Linux to build there, then commit again on Linux and update on
Windows to double-check (and possibly repeat), but this seems to involve
much more work than to just share the sandbox and use the (locally
modified) sandbox from the other system to run a test build. But in
doing so, we need to commit bash scripts with Unix line endings, or else
bash will hiccup.

It seems that in this scenario, it is best to commit bash scripts with
the option to always check out with Unix line endings.


> For the very very very few instances when people can't run CVSNT from
> linux to checkout their linux files we do support the -kl
> substitution mode for unix line endings on windows - but it should be
> the exception.  The very very rare exception. 

This situation has nothing to do with not being able to run CVSNT under
Linux, but with accessing and using a sandbox before committing local
changes from both Windows and Linux.

Gerhard

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev