Ben Collins-Sussman wrote:
...
>>>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?
These are fair questions. I think things probably are different, but it's
worth considering. I'll see what people think about your suggestion
that "adds are rare enough that this is not an issue".
I don't think the pre-commit idea is workable, because, if it guesses
wrong, it could prevent legitamate commits.
>
>> (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.
My intuition is that it would be a bigger deal for us. But, we could try
and find out.
> 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.
I still like my suggestion better. It generates annoying error
messages in the rare case that we add binary files. These errors
are fairly straightforward to deal with.
> 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.
Effectively, this is how CVS works and it works pretty well, in our experience.
CVS assumes native line endings unless a file is *explicitly* maked as binary.
Often when someone checks in a binary file, they forget to mark it as such.
This is easy to fix, once it is detected, although, it isn't always detected as
soon as one would expect. You suggest that adding files is rare.
For most projects, including ours, the great majority of files are text, so
problems with failing to mark binary files are very rare. Line endings for
text files is just not an issue.
> 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.
Great.
Jim
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 30 15:41:52 2004