On Mon, Dec 10, 2012 at 12:26 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 10.12.2012 00:08, Johan Corveleyn wrote:
>> On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>>> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
>>>> 2) Am I the only one who wants to protect his repository against this
>>>> corruption? Judging from [1], I don't think so. It doesn't make sense
>>>> that everyone starts writing this pre-commit hook, for something that
>>>> IMHO is an obvious anti-corruption protection. I think every
>>>> repository out there deserves to be protected against this.
>>>>
>>> FWIW, I suggested a hook because you could implement that in about
>>> 5 minutes, whereas doing a C code change would take at least 10 times
>>> that (and several weeks if you have to wait for it to appear in a 1.7.x
>>> release that you can install at $WORK). I won't object to C code
>>> verifying the svn:eol-style invariant.
>> Thanks. And your pre-commit hook example is much appreciated.
>>
>> For the moment I get the impression that it's not really doable /
>> desirable to implement this in the repository. At least until now
>> no-one has suggested how it could be done, and I don't know enough
>> myself about the server-side / back-end to figure it out :-).
>
> The first obstacle is that the server does not interpret properties.[1]
> Therefore, you'd have to implement this check at transaction-commit
> time, because there's no earlier point where you're guaranteed to have
> all node properties at their final values. This implies that the time to
> reject a commit would be proportional to the size of the commit (which
> isn't the case when it comes to conflict detection).
>
> All properties are interpreted by clients. A buggy client will cause
> cause problems for other users, so the best course of action is to
> report the bug (to SvnKit in this case?).
That's actually pretty hard, because I can't reproduce the issue. I
only suspect svnkit because I've only seen it (at our company) with
commits coming from IntelliJ IDEA, which uses svnkit under the hood.
Another known offender is git-svn, because they don't care about
translating line termination. So if you use git-svn on Windows, you
might end up committing an eol-style=native file with CRLF's in to the
repository.
> Also note that you're using a much too strong term when you talk about
> "corrupted files" in this case. There's nothing corrupted about them.
Well, it does mess up all diffs (client-side, server side for
post-commit mails, ...) made against that revision.
Plus it causes these files to be marked as modified in working copies
of other users ... sometimes (when their timestamps mismatch with
their timestamp-in-wc.db, so the content will be checksummed -- if the
timestamps are still ok, it will not show up as modified). This in
turn can cause totally confusing tree conflicts when a parent dir is
moved (confusing because there's a "local edit" that the user knows
nothing about).
But okay, "corrupt" may be exaggerating a bit :-) ...
> -- Brane
>
> [1] Not strictly true since mod_dav_svn will look at svn:mime-type when
> serving the content at its default, unversioned URL; but it doesn't
> actually interpret the value.
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
--
Johan
Received on 2012-12-10 01:26:32 CET