我和我的兄弟和朋友一起经营一家小型网络开发公司。经过广泛的研究后，我决定使用subversion进行版本控制。
以下是我目前计划如何运行典型开发。请记住，我们每个人都在一个不同的位置。
我使用springloops（springloops.com）subversion托管设置了一个帐户。每次我处理一个新项目时，我都会为它创建一个存储库。所以我要说在这种情况下我正在使用site1。我希望在互联网上有3个版本的网站：
每个Web开发计算机（在每个位置）都将拥有运行虚拟主机的xamp的本地副本，以允许处理多个网站。本地副本的根目录设置为与subversion存储库的本地副本相同。这是设置所以我们可以进行小调整并立即预览它们。完成某些工作后，将对该站点的存储库进行提交。我将自动推送开发站点（它是springloops中的一个选项）。然后，每当我准备好推送到客户端站点时，我都会这样做。最后阶段将是推送到现场。
现在，我对这些工作流程有一些顾虑：
我目前正在使用codeigniter，在配置文件中我通常会设置网站的根目录。防爆。 http://www.site1.com。因此，看起来每次我发布到其中一个互联网服务器，我将不得不修改配置文件？有没有办法让它为每个服务器设置某些文件？因此，当我点击发布到客户端预览时，它只会上传客户端预览服务器的配置文件。
由于各种原因，我不希望实时站点，客户端预览站点和开发站点共享同一个mysql服务器。那么这又是否意味着我每次推送到不同的站点时都必须调整数据库服务器信息？
这个工作流程有意义吗？如果您有任何建议，请告诉我。我计划将此作为我未来几年使用的工作流程。我只需要建立一个允许未来扩展的系统！
答案 0 :(得分：2)
对于分布式版本控制系统有比颠覆更好的版本控制解决方案，我强烈建议您研究其中一种：
另外，正如vittore所说，我认为CI解决方案非常有用，可以将您从开发环境的推送自动化到“生产”，客户可以在成功的构建/测试周期中看到它。 p>
答案 1 :(得分：1)
1）研究持续整合的概念。 （对于小型项目CI服务器，有十几个免费的，例如TeamCity）
2）拥有1.准备可以针对您的三个环境中的任何一个的部署过程
3）考虑总是检查部署的用户是否可以访问.svn文件，因为它确实不安全
还阅读了有关在SVN中使用标签/分支的内容
接下来，我将提出以下工作流程
第一种情况（简单） 每个人都结帐并在本地副本上工作。 提交（经过充分测试）的新功能，您的触发器（可能是自动）预览即可构建 通过全面测试预览，您可以触发建筑生产
第二种情况（更好） 每个人都会在每一次大量的变化中成为一个分支，并且可以自由地向他自己的分支做出任何贡献。 在具有分支稳定分支之后，将其合并到主干，触发测试机器检出并构建您的名称预览并标记标记 经过全面测试的预览将发布到分支
指向拥有这么多分支机构的目的是能够立即存储个人变更历史记录和稳定版本。
答案 2 :(得分：0)
您不希望将存储库的根目录用作工作副本的根目录。这使得之后无法真正使用分支。 （或者你会在本地检查所有分支机构..制作Subversion的廉价副本，工作副本价格昂贵）