我对Subversion / Source Control很新，所以我想知道这是否可行。
我已经安装了一台2012服务器，它将作为我们所有脚本（主要是Powershell）的中心位置。它将托管执行监视任务的生产脚本以及我们的SysAdmins使用的各种其他有用/临时脚本。
现在，我想实现某种形式的源代码控制/颠覆，以便我们可以跟踪对脚本所做的更改。但是，我不确定我想要的那种场景是否可行。
我想要一个名为E：\ Scripts的文件夹，其中存储和执行所有脚本。
但是，每当有人想要更改该文件夹中的脚本时，他们就不应该直接编辑它，而是通过一些源控件/ Subversion工具（例如TortoiseSVN）。
现在，我已经和TortoiseSVN玩了一下，但也许我不明白它是如何运作的。我创建了一个存储库（E：\ SVN）并将E：\ Scripts文件夹添加到其中。我可以签出一个脚本并对其进行修改，但是当我提交更改时，它并没有更新E：\ Scripts中的脚本（我认为它会，也许我错了）。
这种情况可能吗？
答案 0 :(得分：1)
我们使用完全相同的设置，源代码控制PS脚本并从我们的本地副本运行它们。
在另一位开发人员提交并且您想要更改之后，右键单击e：\ scripts文件夹并找到SVN更新。这会将最新的存储库更改加载到本地副本
如果您没有显示屏幕截图中的上下文菜单，则需要在本地计算机上安装SVN客户端
答案 1 :(得分：1)
是的，很有可能。事实上，这就是Source Control的全部内容......
如果您有Subversion存储库，（并且您使用的是Apache或svnserve - 请勿使用file:///！），您可以轻松地执行所需的操作。
我认为E:驱动器是共享的。没有必要这样做。相反，每个用户都将拥有Subversion存储库的工作副本。此工作副本将在用户自己的系统上本地。只需进行Subversion结帐，他们就可以在本地系统上获得所有PowerShell脚本的最新版本。如果他们做出改变，他们就可以做出改变。如果他们想要获得最新的更改，他们会进行Subversion更新。同样，所有这些都在本地系统上。
现在，让我们采取略有不同的方案。您希望这些脚本位于生产服务器上，以及最新版本。您可以使用Jenkins之类的持续集成系统来帮助您。
Jenkins可以观看Subversion存储库，当它检测到更改时，将更新它自己的工作副本。您可以将此工作副本放在任何位置。例如，您可以让Jenkins签出在某个共享目录上定义的工作目录，该目录可供所有服务器访问。当有人更改脚本并检入该更改时，Jenkins将更新其工作副本，并且所有服务器将自动获得更改。
某些网站使用特殊的生产分支。这样，开发可以像往常一样在trunk上进行测试等。但是，当他们准备好在服务器上安装更改时，他们会将更改合并到 production 分支上。他们的Jenkins服务器将看到更改，并更新其工作目录，恰好是所有服务器都可以访问的共享目录。
顺便说一下，PowerShell可以很好地与Subversion命令行客户端配合使用。您可以在安装TortoiseSVN时安装Subversion命令行客户端。这可能是将PowerShell与Subversion一起使用的好方法。
答案 2 :(得分：0)
现在，我一直在玩TortoiseSVN，但也许我不明白它是如何工作的。我创建了一个存储库（E：\ SVN）并添加了E：\ Scripts文件夹。我可以签出一个脚本并对其进行修改，但是当我提交更改时，它不会更新E：\ Scripts中的脚本（我认为它会，也许我错了）。
这是你的问题：
svnserve作为Windows Service进行设置。 svnserve除外）都无法访问原始存储库目录。版本控制的目的是为每个用户提供他们自己的私人工作目录。每个用户在自己的机器上进行结账。每个用户在自己的机器上进行提交。这允许用户共享存储库而不会相互干扰。如果用户在共享驱动器上共享工作目录，则它们将相互干扰。
foo.ps1和bar.ps1进行两项更改。foo.ps1进行更改。foo.ps1，现在正在修改bar.ps1。foo.ps1时，用户＃2编辑bar.ps1。bar.ps1中提交部分更改。此外，用户＃2删除了foo.ps1中的一些更改，因为他们不知道它们的用途。如果每个用户都有自己的工作目录：
foo.ps1和bar.ps1进行了更改。foo.ps1进行更改并提交。用户＃2从未看到用户＃2发生变化，并且不会尝试删除它们，因为他们不知道他们的目的是什么。因此...
svnserve使用。）svnserve。触及原始的Subversion存储库目录是禁止的，除了Subversion管理员之外，所有人都无法访问它。