From: Rafaël Carré <rafael.carre_at_gmail.com>
Date: Sun, 13 Jun 2010 15:17:32 +0200

On Sun, 13 Jun 2010 11:02:08 +0200
Dominik Riebeling <dominik.riebeling_at_gmail.com> wrote:

> On Sun, Jun 13, 2010 at 1:53 AM, Rafaël Carré
> <rafael.carre_at_gmail.com> wrote:

> > - executable
>
> git keeps track of the x bit too, so why should keeping track of this
> in svn (though by using different means) be useless?

Ah I thought svn tracked the permissions, but this property is actually
needed

> > - mime-type
> > This one might be useful for ViewVC web interface, to show images in
> > the web browser (or so I was told), but UsingSVN advises to use
> > application/octet-stream for binary files.
>
> Subversion only distinguishes between binary and non-binary files. All
> files without svn:mime-type or with svn:mime-type set to anything else
> than plain/* are treated as binary files. Using
> application/octet-stream is completely fine for binaries, but setting
> it to image/png (or whatever format the file is) on images allows
> ViewVC to display them inline. This is a nice plus.

Should we add this to the wiki on UsingSVN ?

> However, the important part about svn:mime-type is that it changes
> *subversions* handling of the files. Subversion will try to merge
> local changes with repository changes on updates. This will cause all
> kinds of failures on binary files, so subversion *needs* to know that
> binary files are binary files to stop it from doing these (line-based)
> merges on update. At work I have to use svn, and I've seen quite a lot
> of problems coming from this (which is also caused by the fact that
> people at work are committing all kind of binary blobs. One example
> for such problems are the IntelliSense files created by MSVC. The
> moment you open the project those files will get changed, and doing an
> update will for sure mess things up given the fact that people commit
> that file. MS Office files are another example).
>
> This information is pretty easy to find on the net, it took me only a
> few seconds to back up what I had in my head. See
> http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html.
>
> So this property isn't "useless". It's in fact vital to keep the
> repository working properly.

Ok

> > And I have no problem with the other ones being present as they
> > aren't used in my checkout anyway.
>
> svn:executable is. The man page of git-svn on my system says "We
> ignore all SVN properties except svn:executable." so I expect that
> property to get tracked and set properly. The commit you mentioned
> does show svn:executable getting set in the same commit.

Right, I'll try to remember this when I commit an executable from SVN.

> > If you do want to use them, then just do it, but I won't because
> > it's just wasting my time for no practical use.
>
> Seriously, I find such an attitude quite inappropriate. If you refuse
> to use keywords you basically require others to "clean up" behind you.
> In the worst case you would even have others to do additional work
> (read: waste time) because you don't want to "waste time" by using the
> tool according to the consensus / as intended. Something I don't find
> appropriate, especially given the fact that all work is done by
> volunteers.

My message sounded a bit harsh, I'll try to rephrase it:

I don't want to break the setup of other developers, but I also don't
want to spend time on something which is barely used by anyone (like
the Id keyword).
Sometimes I see a commit which adds this keyword and I'm reminded of
their existence, but most of the time I just don't think about them.

> > I could continue to pretend forgetting about them, but it would be
> > nicer if we just remove these constraints about setting properties
> > from our conventions, or just indicate them as a hint and not a
> > requirement.
>
> As I stated above, some of them are not just a convention we could
> indicate as hint. As far as I can see svn:keywords is debatable.
> svn:mime-type is not. And svn:executable is already handled by
> git-svn.

About mime-type, I don't think we are going to commit any binary file
which is not an image, so can we just make a list of extensions/mime
types which could go in .subversion/config , so the mime types are set
up automatically at each commit ?

png, jpg, pdf, svg, bmp should be enough.



About eol-style, I think we should just ignore this one and force unix
line endings in every file.

Perhaps with a pre-commit hook which checks for the presence of \r in
text files ? I don't know if it is possible to do this on svn clients
rather than on the server.



And is keywords = Id really needed for someone, or can we live without
it ?

-- 
Rafaël Carré

Received on 2010-06-13