Hi Tim, Tim Peters wrote:

...

There's a svn property you can set on a higher level folder in the repository that can control a mapping for file extensions to this property, IIRC. I am hazy on it but I know it's possible.

If so, it's not documented. Perhaps you're thinking of the svn:ignore property?

Damn, that's it :-S Is it worth asking on the SVN lists how hard this would be to implement? I mean, we have the svn:ignore property, and we have the svn:eol-style property, what we want is a combination of those two, how hard can it be? <0.5 wink>

glob-based eol-style property addition can be specified in your svn config file's auto-props section, like

[auto-props] *.c = svn:eol-style=native *.png = svn:mime-type=image/png

but there's no provision for sharing such personal settings with other people (the config file belongs to the user, not to the repository).

Yep, the above is what I do. I suppose it's still one step up from CVS where you have to specify the binary-ness of each file you upload rather than being able to put a mapping i na config file... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

[Chris Withers]

... Is it worth asking on the SVN lists how hard this would be to implement? I mean, we have the svn:ignore property, and we have the svn:eol-style property, what we want is a combination of those two, how hard can it be? <0.5 wink>

I don't think we want a combination of the two: like .cvsignore, svn:ignore only applies to the contents of a single directory (the one on which svn:ignore is set). We'd really like something global (e.g., .py files are text files throughout all of Zope's code). The svn config file is global (or global enough <wink>). Jim and I bugged the Subversion folks last week. Ben Collins-Sussman replied (in part): http://www.contactor.se/~dast/svnusers/archive-2004-04/1373.shtml At this point, the user community has made it absolutely clear that we really need a repository-side configuration which somehow 'broadcasts' runtime configuration options to clients, such as auto-props. Yes, it's burdensome to force every client to hand- maintain auto-props. For now, you'll need to choose between that burden, or the burden of occasionally fixing a mistake when someone forgets to activate native eol style. There's another difference between cvs and svn here: if you forget to mark a file as binary in cvs, it can be hard to recover from. If a Windows user checked it in, the file in the repository may be corrupt. If a Linux user checked it in, and a Windows user grabbed it before -kb was added, the Windows copy may be corrupt, and cvs won't repair that by magic when -kb is added (a cvs update doesn't consider the Windows working copy to be out of date). svn's story is much better (perfect, in fact) when forgetting to add eol-style: regardless of which kind of platform did the commit, the property can be added after the fact by anyone, and svn will automatically repair working copies on all platforms. Because (most) svn properties are versioned, adding eol-style is enough to convince svn that pre-eol-style copies are out of date. Nobody even needs to bother running dos2unix or unix2dos; just adding the property is enough (and when the person who adds the property commits the change, svn fiddles the line ends on their working copy (if needed) by magic too).

Chris Withers wrote:

Tim Peters wrote:

...

svn's story is much better (perfect, in fact) when forgetting to add eol-style: regardless of which kind of platform did the commit, the property can be added after the fact by anyone, and svn will automatically repair working copies on all platforms. Because (most) svn properties are versioned, adding eol-style is enough to convince svn that pre-eol-style copies are out of date. Nobody even needs to bother running dos2unix or unix2dos; just adding the property is enough (and when the person who adds the property commits the change, svn fiddles the line ends on their working copy (if needed) by magic too).

Cool :-)

Glad to find this one is a non-issue!

Well... Non-issue it is not. But it makes it much less of an issue. It would still be nice to have server-side configurations of defalts, though.