subversion
Issue 1974

I've tried finding this issue, and issues 1002, 1233 and 1813 come close-ish,
but they are not what I am looking for.

I am using a SVN repository with Apache httpd for a java project. The project
directory has all kinds of files in it: java source, pdf files, word docs, excel
files, etc. I would like these files to have the correct svn:mime-type property
when I (or my coworkers) add a file. Setting the mime type is great in
combination with Apache and browser access. The usual way to do this is through
the auto-props feature on the _client side_. This has turned out to be a pain to
work with.

First, I (as SVN repository admin) have no way to enforce "good use" with a
"cvswrappers" type of file. We needed to make a separate .reg file for the
autoprops settings, keep that under version control, and make sure that
everybody merged this when they started working on the project, on a new
machine, or when Windows had been reinstalled (oh yes that happens sometimes
:)., etc.

Second, the client config settings are not per repository. I have a case where
in one repository the HTML files are docs and should be text/html, and another
repository where they are source and they should be text/plain... no can do with
a global client config...

------- Additional comments from Ben Collins-Sussman Tue Jul 27 08:58:35 -0700 2004 -------

Serge, your request duplicates what we've seen people ask for at least a hundred
times on the users@ list:  namely, the ability for a server to 'broadcast'
config settings to clients.   But to my surprise, there doesn't seem to be an
issue filed on this yet, despite the fact that we keep talking about it.

Changing from enchancement to feature.

Changing description to be more broad.  (auto-props settings is only one of many
things a server could 'broadcast' to clients.)

This is probably a 2.0 feature, not sure.  Depends on how it's designed.

I think it should now be possible to mark a bunch of other issues as dependent
on this one, if someone has the time to look through the issue-tracker.

------- Additional comments from Stefan Küng Tue Jul 27 09:22:56 -0700 2004 -------

Wow, that issue is exactly what I would need.

For a good integration of Subversion clients with bugtracking tools I would need
the following server based config options:

- a pattern to append to log messages containing the issue number so a commit
can be assigned to an issue by the bugtracking software automatically by parsing
the log message. Such a pattern could look like this:
[bugtracker]
Logpattern = BugID: %d

- to assign an issue number to a specific file before each commit a property
could be set (e.g. name=bugtracker, value=issue-nr:xxx, xxx, xxx). Now a
Subversion client could have a command "show bug(s) associated with file" which
would parse the file for that property and then start the webbrowser to show all
issues found in that property. But to do that the URL of the bugtracker of the
project is needed. So this is again a configuration which should be stored on
the server:
[bugtracker]
IssueURL = http://bugtracker/project/Issues?xxx

So if such configs don't get officially into Subversion (which I doubt), then
I'd like to ask for the configs to be "client expandable". And maybe a list
somewhere to add such client configs so that other clients can choose if they
want to use those or not.

I was already thinking on how this could be implemented (this issue didn't exist
yet):
- the config file would be stored in the repository root, named e.g. PROJECTCONFIG
- on each update/checkout/... the client would check if that file exists and if
yes get this file and store it. I was thinking of storing it in the users
directory (i.e. like the auth data for a repository is stored now).
- whenever those config options are needed, just get it from the users directory
and merge them with the normal subversion configs (they would have of course
lowest priority so the user can override those server configs if needed).

Just an idea.

------- Additional comments from Michael Pryor Wed Jul 28 09:23:54 -0700 2004 -------

As a bug tracking vendor, I have to second Stefan's comments, as this is 
exactly what we need to tightly integrate with Subversion (which we use in 
house, and recommend to our customers).

This feature would allow for the integration to extend *back* to SVN so that 
while browsing your source you could see which cases were associated with a 
particular file (through some sort of web browser hook).

But different checkouts may be associated with different bug tracking projects, 
so there has to be some way to configure this per checkout.  Stefan's 
suggestion of using a CONFIGFILE would work, but to make it not repository 
dependent, maybe the client could look for the file up the directory hierarchy, 
similar to how .htaccess works for apache.  Lower CONFIGFILES on the hierarchy 
would override higher ones.

------- Additional comments from Greg Hudson Wed Jul 28 12:56:08 -0700 2004 -------

Whenever this comes up, I see people tending in the direction of allowing
arbitrary .subversion/config values to be specified by the server.  So, let me
suppress that idea, since it would be a huge security nightmare when it comes to
options like diff-cmd.  Any server-to-client configuration infrastructure we
make must operate on a small, specific set of configuration data which fall
within the purview of the repository, such as auto-props and MIME client detection.

------- Additional comments from Peter N. Lundblad Thu Oct 7 13:28:57 -0700 2004 -------

*** Issue 1841 has been marked as a duplicate of this issue. ***

------- Additional comments from Stefan Küng Thu Jan 13 10:19:00 -0700 2005 -------

About how I think this could be done without breaking older clients at all:
define a file named 'svnrepoconfig' which resides in the repository root. It's
treated like a normal file, unless it's
1. located in the repository root
2. has a special new svn property set (e.g. svn:repoconfig = yes)
If those are true, then it's not a normal file anymore but one that get's
transferred on every update/commit. The client will store it inside the config
area, maybe in a subfolder called 'repoconfigs' right beside 'auth' folder.
To reduce the data traffic, that file could even be 'versioned' like other
working copy files, with the difference that it's stored in the config area.

That way,
- older clients won't break
- the repository root is usually not from where you check out a working copy, so
it won't interfere with normal files kept under version control
- with mod_authz_svn you can set the access rights so that not everyone can
change those settings
- you don't need to contact the repository to get the configs - they're stored
locally so every client can access them immediatley if needed.

------- Additional comments from Hendrik de Goede Thu Mar 31 05:55:14 -0700 2005 -------

I am somewhat amazed that this feature request has been pushed to the 2.0 target
milestone. I can understand that a lot has to be done, and priorities have to be
set. But in a server/client setup, one could expect the server being able to
dictate certain settings to it's clients.

Imagine if one could not have network servers dictate certain settings to the
work stations that log on to them. I guess that would create a lot of work for
many network admins changing settings on each work station by hand (or sending
instructions around and hoping the users take action immediately).

Please, please reconsider this decision, please.

p.s. All the hard work already in Subversion is offcourse really appreciated, it
still is a great product (even without this feature).

------- Additional comments from Stefan Küng Tue Apr 12 10:13:06 -0700 2005 -------

Add tortoisesvn keyword. Reason:
TortoiseSVN currently has implemented some 'configurations' as folder properties
because there's not such thing yet as server-side configs. But folder properties
are not the optimal way to do this.

------- Additional comments from Daniel Grace Mon May 16 13:37:27 -0700 2005 -------

I'm a relatively new user of Subversion, using it for about a month or so for a
project where I'm the sole developer but there's a need for multiple releases

Would a "svn:autoprops" property set on a per-directory level solve some of
these problems?  I imagine the syntax would be similiar to an auto-props file on
the client but with the properties only applying to newly-added files in the
directory.

For example, to set svn:eol-style to 'native' on all new PHP scripts in my src/
directory, I could:

# cat << EOF > props
*.php = svn:eol-style=native
EOF

# svn propset svn:autoprops -F props src



Of course, this design lacks the ability to recurse into subdirectories and
such, but I'm sure it can be expanded there -- at the least, this is a start.

------- Additional comments from Martin Demberger Fri Sep 1 03:48:23 -0700 2006 -------

Why not use a property "svn:config-file" that points to the relative or 
absolute path of a config-file. (If a http:// or svn:// is accepted, the config-
file can be inside the repository itself)
So its possible to set the auto-props for directories and not only for 
repositories.
In addition it might by easy to implement, because the property can be used 
like the --config-dir parameter.

It might also be good, if the svn:config-file is recursivly searched on the 
server and entries of the different config-files are merged.

------- Additional comments from Rainer Müller Fri Sep 1 05:05:54 -0700 2006 -------

It is not that easy to use a property with a path to config file, because it has
to be possible to use it on every directory. Even if you don't check out the
parent directory, you need the config-file itself. Therefore this file has to be
included in every single directory in order to check it out from every hierarchy
level. It would not be possible to easily maintain such a structure.

------- Additional comments from Garrett Rooney Fri Sep 1 05:13:35 -0700 2006 -------

Please take discussion of this issue to the dev list, the issue tracker is not a
good forum for a design discussion.

------- Additional comments from Karl Fogel Thu Mar 20 08:07:27 -0700 2008 -------

In this message:

   http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=76039
   From: Greg Thomas <thomasgd@omc.bt.co.uk>
   To: users@subversion.tigris.org
   Subject: Re: Security flaw: subversion stores passwords by default
   Date: Thu, 20 Mar 2008 09:59:55 +0000
   Message-ID: <14d4u35ek35a20i009adj9sofda8s0ft84@4ax.com>

Greg Thomas proposed an interesting use for such server-broadcast configs: to
let the server indicate to the client whether or not storing plaintext passwords
is a good idea.  (Yes, I've seen Greg Hudson's comments in desc5, but I think
this is one area where it could be appropriate for the repository to indicate a
preference, since the repository admins know the sensitivity of the data, after
all).

Taking Greg Thomas's idea a bit further:

Clearly the client must be the final decider, since the server is powerless to
compel it to store passwords one way or another.  But the default setting we
ship with in the client could be 'store-passwords-unless-repos-says-not-to'. 
There could be two other settings: 'always-store-passwords' and
'never-store-passwords'.  That is, our current boolean becomes a troolean.
(I'm just making up the names of the options, don't take those names as actual
suggestions.)

I wanted to record this idea here so we don't forget it, but any further
discussion should of course take place in the thread above.

------- Additional comments from David Smiley Fri Sep 26 12:52:51 -0700 2008 -------

This issue seems closest to what I am looking for but I envision something
simpler.  In any '.svn' directory on the client, have there potentially be a
'client' file that is in the same format and supersedes that of the user's
~/.subversion/client configuration.  This 'client' file would be something
version controlled and so I would be able to add such a file for a particular
project as typically the first order of business before adding content.

There are concerns to iron out like the fact that some clients might be older
and so might not honor it, and this is NOT some kind of server-side enforcement
mechanism, but it's a hell of a lot better than the current situation.

------- Additional comments from Carlos L Sanchez Sat Dec 4 16:39:44 -0700 2010 -------

It seems that this would also address the issue we are currently having, but to
make sure allow me to detail it below, also to:
  * Ensure that I am not missing any already available options.
  * Share a possible workaround.

---------------------
We are currently working with the Rational Method Composer (RMC) whose design
makes it impractical to merge certain files (e.g. the key plugin.xmi's). We thus
want to ensure that these files are systematically locked before being updated,
i.e. that they always have the "svn:needs-lock" property set. 

The only current standard way (*) to ensure this seems to be to have each
developer update their client machine's Subversion configuration. But as someone
else said, this manual management of the Subversion configuration is
error-prone. So the solution seems to be to allow the Subversion configuration
to be managed from within a working copy, so that its management can be
automatically replicated.

---------------------
A possible workaround, which I haven't explored, could be to map the local 
       C:\Documents and Settings\<USER>\Application Data\
folder to the server Subversion repository "root", so as to put the local
Subversion configuration file under version control in a way that would make any
updates obvious (as long as everyone always syncs from the "root").

But this:
  * Might be too constraining. (And would e.g. require to ignore most sub-nodes
under the "Application Data" node.)
  * Would not address the different needs for different working directories, as
someone else expresses.

---------------------
(*) As someone else indicates, TortoiseSVN's "alternative method is to set the
tsvn:autoprops property on folders" which "does get propagated to all working
copies on update" but "only works for TortoiseSVN clients". But our client might
prefer to use Subclipse from within RMC…

------- Additional comments from Stefan Sperling Sun Dec 5 03:33:38 -0700 2010 -------

Carlos, as another workaround, you could use a pre-commit hook that makes sure
svn:needs-lock is set on files called "plugin.xmi". If it isn't set, make it
print an error with a URL pointing people to a known-good configuration file
they can use.

------- Additional comments from Carlos L Sanchez Mon Dec 6 08:16:21 -0700 2010 -------

Thanks Stefan, and catching missing configurations is good, but preventing them
is better ;-)

Regarding "catching": 

  *** I have found some examples of such pre-commit hooks on the Web, but they
seem over-complicated: are there "official" examples somewhere?

Regarding "preventing": 

  *** Is this fix still only scheduled for v1.8? I would add my vote for a
"sooner rather than later" solution... 

  *** And it seems to me that TortoiseSVN's specific "tsvn:autoprops" folder
property:
          --- Satisfies all expressed needs (even though there was a dissenting
voice, who may want to elaborate): it is "propagated to all working copies on
update", it allows for different configurations for different peer- or
sub-nodes, etc.
          --- Could thus (and quickly?) be promoted from TortoiseSVN-specific to
Subversion-standard.

------- Additional comments from Bert Huijben Mon Feb 9 16:35:43 -0700 2015 -------

While we don't call this issue closed (yet) Subversion 1.8 introduced 
the 'svn:global-ignores' and 'svn:autoprops' inherited properties that might 
resolve the original use case.

------- Additional comments from Sven Fri Feb 27 06:07:42 -0700 2015 -------

It's actually svn:auto-props not svn:autoprops.