On Thu, 2004-04-29 at 16:50, Jim Fulton wrote:
> > This is bad, bad, bad. You're basically giving the SVN client
> > permission to change bytes within binary files. Get ready for corrupted
> > binary files!
>
> No, because subversion prevents setting this property for binary files.
>
Ah, good. I had forgotten about that.
> > Instead, set a pre-commit script which examines newly added files that
> > match a certain set of extensions (.txt, .c, .h, .java, etc.) If
> > somebody forgets to set the 'native' eol property, then bounce the
> > commit.
>
> So, I assume you intend that people would need to manage a set
> of [auto-props] rules, and that this would be something to show bugs
> in thier rules.
Not necessarily. The pre-commit hook simply throws an error: "commit
rejected, because you didn't set native-eol-style on the new source
file." Whether an individual user wants to use [auto-props] to help
with that is a personal choice; nobody's forcing them to use
auto-props. The user can simply see the rejected commit and hand-add
the property too.
Honestly: how often do you add new source files to a repository?
Around here, it's a pretty rare event. Are things quite different in
the zope community?
> (Surely, you don't expect people manually set
> svn:eol-style on every text file.)
Well, that's what most svn developers do. But then again, new files
don't show up very often for us. Once in a while, one of us forgets to
set native eol style on a new file. When that happens, it's discovered
pretty quickly (easy to spot!), and fixed pretty quickly as well. It's
not a huge deal.
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.
It seems a bit weird to blindly attempt to set svn:eol-style on every
file in sight, but I also understand how that may be a reasonable
workaround for now.
And yes, you make a good point about 'svn add' bailing out as soon as it
reports an error trying to set svn:eol-style on a binary file. If
others agree, I could see this being filed as a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 30 00:17:23 2004