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

On Sun, Jun 13, 2010 at 1:53 AM, Rafaël Carré <rafael.carre_at_gmail.com> wrote:
> I think the svn properties used in rockbox are useless and a waste of
> time.

They are not. While some are debatable (like svn:keywords) others are
*required* by the used tool, i.e svn.

> Even more when I have to maintain a separate svn checkout only for the
> purpose of setting them, but also when just using Subversion tools.

If you chose to use a different tool than the one that was agreed to
use (i.e. git-svn instead of svn) it's still your responsibility to
follow the consensus. If this means you have to keep a svn checkout
around just to set properties then that's the price you pay for using
git-svn. It's up to you to decide if you want a different tool, but
it's not up to you to decide to not follow the consensus.

> - eol-style
> I don't even know if this should be set to native or 'LF'.

I don't think there is a consensus about svn:eol-style (as I've
already wrote earlier). This should get clarified and documented in
the wiki.

> - 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?

> - 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.

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.

> - keywords (Id)
> That one really serves no purpose, if you need to know the history of a
> file just use svn/git log/blame.

While I agree with this a lot of people like keywords. I've seen
enough people even wanting the *complete* *commit log history*
(*cough*) in the files and complain about svn (fortunately) not
supporting the $Log$ keyword cvs had. However, as those are only
informational and don't change anything important I don't see a
problem with not setting them. I wouldn't mind to get rid of keywords
completely.

> Beside this uselessness, it also causes harm when the expanded keyword
> is present in patches.
> I don't know how/why but it does happen.

I think some people creating patches are confused by the keywords line
and edit it manually. Which of course, will show up in the diff.
Another reason would be to create a diff without using svn diff, and
probably even creating the diff against a different checkout which
might have the Id line expanded differently. I never had problems with
keyword in diffs created via svn diff.

> 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.

The executable bit can cause problems. Some experience I made a while back:
I did create a git repository from a svn one using git-svn on cygwin.
No executable had the svn:executable set (as its usually not needed on
Windows and this was in a Windows-only environment). However, running
the executables in that checkout failed badly (with interesting error
messages like "can'f find <exectuable>" with <executable> being the
one just clicked in Explorer!). This even failed for plain cmd
scripts. Setting svn:executable fixed that issue. I found out that
this was caused by cygwin trying to emulate POSIX file permissions
using Windows ACLs. I haven't completely figured what cygwin did here
in detail (the contents of files security attributes view looked sane)
but it definitely caused problems, and after settings svn:executable
in the svn repository it worked.

> 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.

> 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.


 - Dominik
Received on 2010-06-13