On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia <nkadel_at_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.
Received on 2011-11-10 15:13:50 CET