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

Is there any way to set an EOL style on svn:externals?

From: Dan Stromberg <dstromberglists_at_gmail.com>
Date: Thu, 08 May 2008 18:04:45 -0700

Is there any way to set an EOL style on svn:externals? I know you can
set it on a checked in file, but what about on another property?

I keep getting windows users checking in svn:externals changes with
inconsistent line endings, and that makes "svn propget" and "svn
propedit" choke. I have automated processes that are doing "svn
propget" followed by "svn propset" if there are changes, so it's
probably just a matter of time until such an issue (which means svn
propget fail to return the list of externals) causes an svn:externals
update to be missed.

I have a case-by-case fix (vi .svn/dir-prop-base, remove the carriage
returns, carefully adjust the preceding length to reflect the lower
number of bytes - note that just using dos2unix or ftp in ascii mode
doesn't work fully because of the length that needs to be adjusted), but
is there a longer term fix? One where I don't have to catch the problem
in time?

Alternatively, and this is a distant second in desirability, is there a
way of using a hook script that'll detect the inconsistent line endings
and either fix them on the fly or at least reject the checkin?

Or should I just write something to automate the vi method I sketched
above? ISTR hearing that editing things under .svn is a Bad Thing, but
if I'm doing it manually anyway...

And why does svn propget /care/ about the EOL inconsistency? I
understand why you wouldn't want to change the EOL convention on the fly
for a regular file, but for svn:externals maybe it's not important to
avoid auto-converting.


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-09 03:05:54 CEST

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.