On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell <lesmikes...@gmail.com> wrote: > On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> >> I spent a *lot* of time explaining this to verious people trying to >> use multiple platform shared access, and running headlong into the >> problems they thought they'd "cleverly" worked around. It became an >> adventure to explain why svn:eol should be deprecated, preferably with >> a claw hammer. > > Ummm, no. Using other ways of move files across systems that need > eol-munging shouldn't have been considered in the first place. There's > a long, long history.
Les, "moving" wasn't the problem. Inheritance was. People who'd not paid attention to their CVS->Subversion migrations, or inconsistently laid defaults and inherited svn:eol settings of any kind were alarmed when their working copy accessed in Linux for compilation, but managed with TortoiseSVN for the superior management GUI, proceeded to have real end-of-line management problems. And this is *precisely* the sort of issue that can occur with shared network drives. It's especially an issue with files get "added" or "imkported" and a different svn:eol policy gets set, and then you have to *change* it. on the fly. This kind of clean-up whackiness is why constintly setting the EOL as a matter of document type, not local operating system, is so useful.
