Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-1974

server-side config which 'broadcasts' to clients

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: all
    • Fix Version/s: 2.0-consider
    • Component/s: unknown
    • Labels:

      Description

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

      Original issue reported by beaumose

        Issue Links

          Activity

          Hide
          sussman Ben Collins-Sussman added a comment -

          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.
          
          
          

          Show
          sussman Ben Collins-Sussman added a comment - 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.
          Hide
          steveking Stefan Küng added a comment -

          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.
          

          Show
          steveking Stefan Küng added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          

          Original comment by michaelpryor

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by michaelpryor
          Hide
          ghudson Greg Hudson added a comment -

          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.
          
          

          Show
          ghudson Greg Hudson added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

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

          Original comment by lundblad

          Show
          subversion-importer Subversion Importer added a comment - *** Issue 1841 has been marked as a duplicate of this issue. *** Original comment by lundblad
          Hide
          steveking Stefan Küng added a comment -

          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.
          
          

          Show
          steveking Stefan Küng added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

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

          Original comment by hdg

          Show
          subversion-importer Subversion Importer added a comment - 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). Original comment by hdg
          Hide
          steveking Stefan Küng added a comment -

          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.
          

          Show
          steveking Stefan Küng added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          
          
          

          Original comment by dewin

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by dewin
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          

          Original comment by martindemberger

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by martindemberger
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          

          Original comment by raimue

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by raimue
          Hide
          rooneg Garrett Rooney added a comment -

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

          Show
          rooneg Garrett Rooney added a comment - Please take discussion of this issue to the dev list, the issue tracker is not a good forum for a design discussion.
          Hide
          kfogel Karl Fogel added a comment -

          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.
          

          Show
          kfogel Karl Fogel added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          

          Original comment by dsmiley

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by dsmiley
          Hide
          subversion-importer Subversion Importer added a comment -

          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…
          
          

          Original comment by carloslsanchez

          Show
          subversion-importer Subversion Importer added a comment - 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… Original comment by carloslsanchez
          Hide
          stsp Stefan Sperling added a comment -

          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.
          

          Show
          stsp Stefan Sperling added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

          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.
          
          

          Original comment by carloslsanchez

          Show
          subversion-importer Subversion Importer added a comment - 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. Original comment by carloslsanchez
          Hide
          rhuijben Bert Huijben added a comment -

          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.
          

          Show
          rhuijben Bert Huijben added a comment - 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.
          Hide
          subversion-importer Subversion Importer added a comment -

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

          Original comment by skoehler

          Show
          subversion-importer Subversion Importer added a comment - It's actually svn:auto-props not svn:autoprops. Original comment by skoehler
          Hide
          mkuhn Markus Kuhn added a comment -

          The original feature request 12 years ago for repo-side control of the [auto-props] configuration of a client was properly fixed in 2013 with the addition of svn:auto-props in Subversion 1.8. It works wonderfully!

          Therefore, I would suggest to close this issue now.

          If there is still any additional centralized-configuration functionality missing that users want, I think it would be much cleaner and neater if the proponents of that opened a new feature request that presents at the top a clear use case for what Subversion is still missing today, so that that can be added to the roadmap instead. Leaving a 12-year old issue open that has actually been resolved years ago only confuses newcomers, IMHO.

          Show
          mkuhn Markus Kuhn added a comment - The original feature request 12 years ago for repo-side control of the [auto-props] configuration of a client was properly fixed in 2013 with the addition of svn:auto-props in Subversion 1.8. It works wonderfully! Therefore, I would suggest to close this issue now. If there is still any additional centralized-configuration functionality missing that users want, I think it would be much cleaner and neater if the proponents of that opened a new feature request that presents at the top a clear use case for what Subversion is still missing today, so that that can be added to the roadmap instead. Leaving a 12-year old issue open that has actually been resolved years ago only confuses newcomers, IMHO.

            People

            • Assignee:
              Unassigned
              Reporter:
              subversion-importer Subversion Importer
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development