I do understand this, but this is not a "bug". It is how Subversion is
designed to work. For strange edge cases, the xml people want content to be
labeled application/xml rather than a text subtype. ... I *do* understand
that this negatively impacts your development workflow.
Note that you can always remove the property after the "svn add", but
before you "svn commit". Others have commented on ways to avoid the
automatic placement of the property, though that will be increasingly
difficult in heterogeneous environments with different svn clients.
Subversion just "helpfully" provides a property, but you *don't* have to
commit it that way. And committing it that way, and removing it later, has
no effect on your actual content.
Your hook is a good way to prevent *new* files with that svn:mime-type on
them. Your repository has tens of thousands now, sure, but honestly... the
concern is about new files, and their rate of addition. It seems once
somebody sees a "cannot merge a binary file" error, then they can just go
delete the property and continue their work.
If one of the knobs that Stefan suggest is not working properly, then we
can track that down and fix it.
Cheers,
-g
On Sat, Oct 3, 2015 at 3:48 AM, Edward d'Auvergne <true.bugman_at_gmail.com>
wrote:
> On 3 October 2015 at 01:05, Greg Stein <gstein_at_gmail.com> wrote:
> > On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
> >>...
> >> As this bad behaviour can be so incredibly damaging for this
> >> repository,
> >
> > Note: the files themselves are not "damaged" -- Subversion will never
> > alter the contents of a file when it is first imported/added. It may
> > make a file look different in the working copy, according to
> > svn:eol-style. But the svn:mime-type is just a property associated
> > with the file. Its only real use is when the file is served via HTTP
> > to a web browser.
>
> Hi Greg,
>
> The damage is to the repository backend and to the development process
> itself. Treating text files as binary has a number of significant
> consequences for development. For example:
>
> - 'svn up' can no longer perform merges (G).
> - 'svn merge' or the svnmerge.py script can no longer function to
> merge changes to the same file.
> - A one character change to a massive text file results in a diff and
> db/revs backend file the size of the whole file, and not just a few
> lines for a proper diff.
> - Changes can no longer be reviewed (
> https://sourceforge.net/p/flightgear/mailman/flightgear-fgaddon-commitlogs/
> ).
>
> This is a severe bug. Here is an interesting sign as well:
>
> $ svn propset svn:mime-type "application/xml" dash-set.xml
> svn: warning: 'application/xml' is a binary mime-type but file
> '/flightgear/repo_testing/mimetype/test1/DaSH_svn_import/dash-set.xml'
> looks like text; diff, merge, blame, and other operations will stop
> working on this file
> property 'svn:mime-type' set on 'dash-set.xml'
> $
>
> Unfortunately 'svn add' and 'svn import' set this binary mime-type
> without warning, and when explicitly told not to.
>
>
> > If a file is committed to the repository with an svn:mime-type, why
> > don't you just delete/correct the property in a following commit?
>
> Does this answer your question ;)
>
> [edward_at_localhost flightgear-fgaddon]$ svn info
> Path: .
> Working Copy Root Path: /flightgear/flightgear-fgaddon
> URL: svn+ssh://edauvergne@svn.code.sf.net/p/flightgear/fgaddon/trunk
> Relative URL: ^/trunk
> Repository Root: svn+ssh://edauvergne@svn.code.sf.net/p/flightgear/fgaddon
> Repository UUID: 9eb9bc84-db9d-4e05-893b-26dd41ac94a6
> [snip]
> [edward_at_localhost flightgear-fgaddon]$ find -type f | grep -v .svn | wc -l
> 69458
> [edward_at_localhost flightgear-fgaddon]$ find -name "*.xml" | wc -l
> 27262
> [edward_at_localhost flightgear-fgaddon]$ find -name "*.ac" | wc -l
> 12502
> [edward_at_localhost flightgear-fgaddon]$ find -name "*.nas" | wc -l
> 2840
>
> Manually monitoring this huge beast is out of the question.
>
> Cheers,
>
> Edward
>
Received on 2015-10-03 11:01:51 CEST