Hello Matt, > I'm very new to Subversion and VisualSVN so I'm not sure if this is even > possible. > > I'd like to have a central share for all our Powershell scripts (there are > currently hundreds of scripts running on countless servers in the > organisation) where all the scripts we use are executed from > > These scripts would be in a shared folder on the server (let's called it > \\SERVER1\Scripts$). The only people who should be able to directly modify > files in there are designated ScriptAdmins (I guess I can use NTFS > permissions for that). > > Now, what I would like to be able to do is to have something similar to the > Advanced Group Policy Managment functionality in Windows Server 2008 in that > anyone who wants to modify a script in that shared folder has to go via some > form of Subversion/Source Control > > So, they would use, say, TortoiseSVN client to check out a script, modify it > and then Commit the change to the repository and those changes would then be > applied to the original source file in the shared folder, Scripts$. > > In my testing, however, the committed changes are NOT replicated to the > Scripts$ share. I presume I am simply misunderstanding how subversion > works? Is there any way to have this scenario?
Since you are new to Subversion, I strongly advise you to read SVNBook to learn more about Subversion and version-control in general. SVNBook is the Bible of SVN and must-read for Subversion administrators and users. See SVNBook at http://www.visualsvn.com/support/svnbook/ * Is there any special reason to keep the most up-to-date version of those PowerShell scripts in the network share? I'm asking because the task you need to complete can be done without using the network share, i.e. with VisualSVN Server and Subversion client only. Here are the steps: 1. Import (i.e. add) your PowerShell scripts to the VisualSVN Server repository, 2. Setup authorization rules for your users so that only particular Active Directory users and groups will have Read and Read / Write access to those scripts. See the article "Understanding VisualSVN Server authorization" at http://www.visualsvn.com/support/topic/00033/ 3. Users and services can checkout a local working copy of the repository that contains those PowerShell scripts. They can view and modify those scripts in the working copy, however only users with Read / Write access can commit changed and/or new scripts to the repository. * If you still want to have those scripts on the network share as well as in the repository, you can store the working copy of the repository in the network share and update it on each user's commit by using Subversion post-commit hook script. See SVNBook | Post-commit at http://www.visualsvn.com/support/svnbook/ref/reposhooks/post-commit/ and SVNBook | Implementing Repository Hooks at http://www.visualsvn.com/support/svnbook/reposadmin/create/#svn.reposadmin.create.hooks In such case, it's important to setup NTFS and share permissions for this share to allow only Read access for your users. The only account that must have Modify (Read / Write) access to the share is the account that runs VisualSVN Server's service because it will update the shared working copy. It makes sense to set deny access rules on ".svn" directory for your users in this working copy. This way it won't be considered as working copy by them. VisualSVN Server's service runs under Network Service account, by default. This built-in account represents computer account's credentials on the network so you have to provide the account with NTFS and share permissions to the network share. Please let me know if you require any additional assistance with this task. Thank you! -- With best regards, Pavel Lyalyakin VisualSVN Team -- You received this message because you are subscribed to the Google Groups "VisualSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to visualsvn+unsubscr...@googlegroups.com. To post to this group, send email to visualsvn@googlegroups.com. Visit this group at http://groups.google.com/group/visualsvn. For more options, visit https://groups.google.com/d/optout.
