On 09.12.2012 09:14, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 01:02:55 +0100:
>> Last week a colleague managed to commit a non-LF-normalized
>> svn:eol-style=native file in our repository again. As explained in
>> issue #4065 [1], this causes all kinds of problems.
>>
>> I suspect there might be a bug in SVNKit, some edge-case where it
>> doesn't correctly translate the to-be-committed files to
>> LF-termination. But regardless, I'd like to protect my repository. I
>> don't fully control the clients that people use, and those clients can
>> always have bugs, ...
>>
>> So ... how hard would it be to fix issue #4065, making the server
>> enforce the right eol-ness for correct operation? It's a genuine
>> question, I have no idea :-).
>>
> for i in $(svnlook changed -t $TXN $REPOS); do
> if propget = native || propget = LF ; then
> svnlook cat -t $TXN $REPOS $i | xxd -c1 -p | grep -i 0d
> fi
> done
>
> And writing that made me realise... "contains CR" is such a simple
> condition, that you don't need the fulltext for it --- you would be able
> to implement it by looking at the "literal new text" segments within
> svndiff streams directly. However, I'm not quite sure whether this
> observation is the key to a simple implementation or to an
> unnecessarily-complicated one.
>
>> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4065 - server
>> should enforce LF normalization for svn:eol-style=native files
The server does not look at the contents of files, or the value of
properties. It does not even know that properties /have/ semantics. The
only reasonable place to do this would be in a pre-commit hook. Anything
else would require a major change in the design of the server and/or
libsvn_repos.
If the client encounters non-normalized files with svn:eol-style=native
and does /not/ properly normalize them regardless, that's a client bug.
Though of course the file would immediately show up as modified as soon
as it was updated.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-12-09 11:43:03 CET