On Thu, Nov 10, 2011 at 8:13 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>
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.
I'm not sure I see a point here. There are lots of things that you
have to get right or things won't work, and this is one of them. We
can't change history and pretend that text is the same on every system
even though the difference looks like a mistake in retrospect.
---
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-11-10 17:57:53 CET