Server side svn:auto-props, how to set it correctly?

Post by Bo Berglund
I would like to set our SVN server to enforce some file properties for
commonly used files such as images and binary files as well as eol
handling between client operating systems.
I have fixed up one repository from the client side using working
copies and the svn_apply_autoprops.py script.
But it feels like I still have to make some *server side* settings
that will stop new file additions to be done with incorrect
properties.
I have tried looking for a manual for svn 1.9 but the only one I have
found is 1.7 and there is nothing about setting up server side
enforced properties. Apart from this there is only a number of
webpages, which I find hard to navigate.
https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config
https://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence
But it is not clear to me HOW one can set these properties....

Obviously you set them on some directory and commit the change.

Post by Bo Berglund
The system I am setting up consists of a number of VisualSVN
repositories each holding a number of projects of certain types. All
Project
|-- branches
|-- tags
|-- trunk
How can I set the auto-props on the server itself

Not on the server, on the root of the repository, which is a directory.

Post by Bo Berglund
such that when
someone imports a new project the files will be assigned the necessary
properties even if they have not properly set up their clients?
I need some exact command descriptions if possible...

For example:

svn checkout ${REPOSITORY_ROOT_URL} ${WC_PATH} --depth empty
cd ${WC_PATH}
svn propset ${PROPERTY} ${VALUE}
svn commit -m "Commit message"

This will set a property on the repository root directory.

Post by Bo Berglund
On the server I found a conf subdirectory in the server root and it
### This file controls the configuration of the svnserve daemon, if
you
### use it to allow access to this repository. (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)
Our access method is via https: through the Apache webserver, so this
conf file is apparently not useful at all...

That's completely irrelevant, it has nothing to do with repository contents.

-- Brane

Bo Berglund

2018-02-16 09:06:42 UTC

Post by Bo Berglund
How can I set the auto-props on the server itself

Not on the server, on the root of the repository, which is a directory.

Thanks,
I thought that the server root was controlled by a server conf file
rather than it being some directory possible to check out.
Is it also possible to put files in the root?
When I used cvs2svn I had errors when there were files in the root of
the CVS repo so I had to remove them. My understanding was that the
top level stuff *had* to be directories rather than files....

Post by Branko Äibej
svn checkout ${REPOSITORY_ROOT_URL} ${WC_PATH} --depth empty
cd ${WC_PATH}
svn propset ${PROPERTY} ${VALUE}
svn commit -m "Commit message"
This will set a property on the repository root directory.

Is this how it would work? :

svn co https://server.svn.repo/ top --depth empty
cd top
svn propedit svn:auto-props ./

editor pops up and I enter all of the lines like:
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
....

when closing the editor the values are applied to the working copy
directory itself?

svn commit -m "log message"

I.e. can I specify the target as the current dir like shown above?

--
Bo Berglund
Developer in Sweden

Branko Čibej

2018-02-16 09:20:05 UTC

Post by Bo Berglund
How can I set the auto-props on the server itself

Not on the server, on the root of the repository, which is a directory.

Thanks,
I thought that the server root was controlled by a server conf file
rather than it being some directory possible to check out.
Is it also possible to put files in the root?

Of course, the root is just another directory in Subversion. Obviously
"directory in Subversion" is not the same as "directory on disk"; the
repository is essentially a database with a tree-like structure.

Post by Bo Berglund
When I used cvs2svn I had errors when there were files in the root of
the CVS repo so I had to remove them. My understanding was that the
top level stuff *had* to be directories rather than files....

No. That is probably a limitation of either CVS or cvs2svn.

svn co https://server.svn.repo/ top --depth empty
cd top
svn propedit svn:auto-props ./
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
....
when closing the editor the values are applied to the working copy
directory itself?

Yes.

Post by Bo Berglund
svn commit -m "log message"
I.e. can I specify the target as the current dir like shown above?

Yes.

-- Brane

Bo Berglund

2018-02-17 07:18:13 UTC

Post by Bo Berglund
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native

Do I also have to handle case here?
I.e. for each file pattern do I have to figure out all case
permutations too?
Ex:
*.cpp = svn:eol-style=native
*.cpP = svn:eol-style=native
*.cPp = svn:eol-style=native
*.cPP = svn:eol-style=native
*.Cpp = svn:eol-style=native
*.CpP = svn:eol-style=native
*.CPp = svn:eol-style=native
*.CPP = svn:eol-style=native

Or is it just the svn_apply_autoprops.py that uses case sensitive
pattern recognition?
I noticed a file not getting the property set when I used it...
It was named in all caps.

--
Bo Berglund
Developer in Sweden

Branko Čibej

2018-02-17 08:40:35 UTC

Post by Bo Berglund
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native

Do I also have to handle case here?
I.e. for each file pattern do I have to figure out all case
permutations too?
*.cpp = svn:eol-style=native
*.cpP = svn:eol-style=native
*.cPp = svn:eol-style=native
*.cPP = svn:eol-style=native
*.Cpp = svn:eol-style=native
*.CpP = svn:eol-style=native
*.CPp = svn:eol-style=native
*.CPP = svn:eol-style=native
Or is it just the svn_apply_autoprops.py that uses case sensitive
pattern recognition?
I noticed a file not getting the property set when I used it...
It was named in all caps.

Paths in Subversion are case-sensitive. All patterns are case-sensitive
too. You'll either have to add all case permutations, as you showed
above, or teach your users some discipline in naming files.

-- Brane

Bo Berglund

2018-02-18 13:56:58 UTC

Post by Bo Berglund
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native

Paths in Subversion are case-sensitive. All patterns are case-sensitive
too. You'll either have to add all case permutations, as you showed
above, or teach your users some discipline in naming files.

OK, I see.
But I have an additional clarification question:

In my local .subversion/config file (on Windows) I have this comment in
the auto-props section. BTW it is the same on an Ubuntu machine:

[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match (case-insensitively) will be <<==
### applied to the file. Note that auto-props functionality
### must be enabled, which is typically done by setting the
### 'enable-auto-props' option.

To me this indicates that the auto-props patterns are case-insensitive.
Or is this a old artifact that has not been updated since it is just a comment?

Or maybe the server side auto-props are case sensitive while the client side is not?

PS:
I usually communicate with this list via the Gmane news mirror, but today I
have found that the gmane.org domain itself seems to have vanished from the Internet!
Too bad if this is not a temporary issue.
Looks not so good if the DNS name disappears rather than the server not responding.
DS

Nico Kadel-Garcia

2018-02-19 01:29:05 UTC

Post by Bo Berglund
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native

To me this indicates that the auto-props patterns are case-insensitive.
Or is this a old artifact that has not been updated since it is just a comment?
Or maybe the server side auto-props are case sensitive while the client side is not?
I usually communicate with this list via the Gmane news mirror, but today I
have found that the gmane.org domain itself seems to have vanished from the Internet!
Too bad if this is not a temporary issue.
Looks not so good if the DNS name disappears rather than the server not responding.
DS

Yes, it is. *Life* is case sensitive. Personally, I'd be startled to
see mixed case in a three-letter suffix, But Subversion is, in many
ways, based on CVS, which was originally written for UNIX and was,
indeed, case sensitive in file name handling. So I'm not surprised at
all by this.

Ryan Schmidt

2018-02-16 11:41:48 UTC

The server-side auto-props feature can *suggest* properties users should use, but if you want to *enforce* that they are used, and prevent commits that don't, you have to write a pre-commit hook script to do that.

Bo Berglund

2018-02-16 14:40:16 UTC

On Fri, 16 Feb 2018 05:41:48 -0600, Ryan Schmidt

Post by Ryan Schmidt

The server-side auto-props feature can *suggest* properties users should use,
but if you want to *enforce* that they are used, and prevent commits that don't,
you have to write a pre-commit hook script to do that.

How can a svn server "suggest" that?

I come from CVS where a file that is not marked as binary is processed
with eol-conversion on ceckout and commit. Not the best of worlds
since one has to be careful with how to add files (as text or binary,
default is text).
If one fails here a binary file will be corrupted. Not good.

But it can be fixed by properly configuring the CVSROOT/cvswrappers
file to specify the file type mapping. So that is how we have used
CVS.

When I started to use svn I suddenly realized that the text files were
checked out with UNIX line endings. It happened when a file I looked
at was opened in Notepad and was a single long line....
Other editors and usually also the dev IDE:s can cope and you do not
really feel the difference. So it took a while to see.

This is why I am looking at ways to stop this from happening and I had
to check out every project of the already converted CVS repositories
and use the py script to set the properties for eol-conversion. But
this only works for these files and any future additions would have to
be properly treated, so this is why I was looking for a way to fix it
server side.
If it is possible to circumvent is another issue because then the
developer will have a reason for doing so and it is OK. But normal
project imports should work without having to fix stuff.
So I don't want to do a pre-commit hook to block this.

--
Bo Berglund
Developer in Sweden

Branko Čibej

2018-02-16 15:20:51 UTC

Post by Ryan Schmidt

That's not true at all. The client will honour the properties it knows
about. Of course in the case of svn:auto-props, these are processed at
'svn add' and the user can change the results before committing; but
they're not a suggestion by any means, they even override client-side
configuration.

-- Brane

Ryan Schmidt

2018-02-16 19:21:40 UTC