[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Network Share Checkouts

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 10 Nov 2011 09:13:17 -0500

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.