有效的工作流，允许设计师访问SVN存储库的一部分

我们有一个开发团队和一个设计团队。让我说清楚。开发人员不是艺术家，设计师也不是那么精通代码

开发人员在机器上本地的SVN存储库中处理web应用程序。我们有Windows 2003工作站，允许每个开发人员在IIS中托管每个网站以进行调试。我们使用OrtoiseSVN和VisualStudio以及VisualSVN

开发人员的功能是让一个新功能正常工作，然后设计师需要进入并对页面、皮肤、css等进行更改，以使其美观，但他们所做的更改需要提交回存储库，以便开发人员可以查看而不被覆盖

从支持的角度来看，让每个设计人员都有自己的IIS服务器可供使用是站不住脚的。我们目前能想到的最佳解决方案是，设置一个设计服务器，对SVN存储库的网站部分进行独立、共享的签出，并允许所有设计师通过UNC共享对该网站进行更改，然后仅使用OrtoiseSVN提交其更改。然后，开发人员将更新以接收这些更改，并将其发布到测试并最终上线

这似乎基本上是可行的——最大的问题是，设计师必须小心，不要相互推诿，只提交他们的更改

还有其他问题我没有考虑吗

有没有其他人能为这种类型的工作流提供更好的解决方案

---

（我在这一个标签上挣扎，任何帮助重新标记都将不胜感激。）

除非我在您的描述中遗漏了什么，否则您应该能够使用分支实现这一点

您还没有详细介绍当前如何进行功能开发/发布分支，因此为了我的示例，我假设开发人员在完成功能后将其合并回主干

一旦发生这种情况，主干应该被分支，设计者应该将他们的更改提交给这个分支

完成后，开发人员可以查看所有更改，并将发布所需的内容合并回主干

---

如果您希望确保设计器不会意外提交任何内容，还可以将其写访问权限限制为仅存储库中的分支路径。

如果您不放松“最多一台IIS服务器”的约束，我看不出如何获得比您提到的方案更好的方案。难道不可能使用虚拟机让每个设计师都可以拥有自己的服务器吗？所有这些机器都可以共享相同的配置文件。这样，设计师就不必担心彼此的变化…

设计师是否使用Visual Studio？如果是这样，那么您可以使用VS附带的嵌入式web服务器，这样您就根本不需要IIS。这就是我所有发展的方式

如果您使用Subversion的分支功能，那么每个设计人员都可以创建自己的分支，并在其中工作，直到他们感到舒适地合并到主干或其他开发人员正在处理的任何版本分支

让每个人尽可能地孤立，往往会让事情进展得更顺利。这意味着没有共享的web服务器。这就是Subversion构建的方法论

---

我喜欢的一个策略是使用一个中继警察。指定一名开发人员负责管理主干。也许您可以只授予此人对主干的写访问权，而她的工作是确保所有到主干的合并都正确完成。很明显，您需要一个在开发和源代码管理（特别是Subversion）概念方面有很强技能的人。

我强烈建议您不要使用建议的分支选项。这对开发人员来说有时是很棘手的，所以我让您想象一下，如果您的所有设计人员开始将各自的分支合并在一起，您将陷入混乱。如果开发人员正在处理主干，您可能需要定期将主干合并到一些设计人员的分支中

一种可能是为所有设计人员提供一个IIS，但每个人（例如johndoe）都将在自己的应用程序（比如）上工作，该应用程序已签出到网络驱动器上（例如i:/johndoe/应用程序）。这样，John可以处理一些文件，并在浏览器中查看结果

当John需要签入他的更改时，您可以让他签入，也可以指定一个“签入伙伴”为他签入。

“最大的问题是设计师必须小心，不要相互干涉，只提交他们的更改。”

您能否在同一IIS服务器区域上为它们提供单独的工作区？（可能是工作区在以其命名的文件夹下签出？）这样，他们只会从自己的工作区提交工作。当然，这假定他们正在处理非重叠代码，因此在提交时不会覆盖彼此的工作。此外，他们还需要在开始工作之前接受svn udpate培训，以便了解所在领域其他人的最新变化，以避免任何冲突。 （当多人使用同一工作区时，我总是很紧张）

您可以让他们进行更改，但不一定让他们运行提交。单个指定人员可以每天运行一次svn commit或更频繁地运行svn commit，以避免任何不幸的错误。我不太喜欢这个选项——因为我认为人们很容易使用多个工作区，并遵循简单整洁的习惯，如提交相关消息等（以帮助跟踪/回滚）——一个简短的握手会议可以轻松弥补知识和思维方面的差距

---

如果设计师对SVN有一个很好的介绍，那就没那么糟糕了。