[reportlab-users] RE: [Zope-dev] Subversion

[Tim Peters]

[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).