On 3 October 2015 at 11:01, Greg Stein <gstein_at_gmail.com> wrote:
> 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.
Hi,
The "svn add", "svn propdel svn:mime-type -R", "svn ci" workflow is
what we currently must use. Though it would be good if we could cut
out the middle "svn propdel" step, as the propdel command can be
difficult to find or missing in certain svn GUI clients (I've heard
this about TortoiseSVN). The big problem is with the "svn import"
command, which essentially combines "svn add *" and "svn ci" into one
without having a local checked out copy of the repository. In this
case, inserting "svn propdel" in the middle is not possible. Anyway,
is it really not a bug when:
enable-auto-props = yes
and:
enable-auto-props = no
both enable auto-props?
Cheers,
Edward
Received on 2015-10-03 11:13:13 CEST