Svn 使用subversion为2-3人的web开发建立完美的工作流

我和我的兄弟和朋友一起经营一家小型网络开发公司。在做了大量的研究之后，我决定使用subversion进行版本控制

下面是我目前计划如何运行典型开发。请记住，我们每个人有三个人在一个单独的位置

我在springloops（springloops.com）subversion主机上建立了一个帐户。每次我处理一个新项目时，我都会为它创建一个存储库。因此，让我们假设在本例中，我正在site1上工作。我想在互联网上有3个版本的网站：

Web开发-这是服务器 我和其他开发人员发布 到（site1.dev.bythepixel.com）

客户端预览-这是服务器 我们每隔几天更新一次 很好的修改让客户看到。 （site1.bythepixel.com）

直播站点-我在直播时发布到的站点（site1.com）

每个web开发机器（在每个位置）都将有一个运行虚拟主机的xamp本地副本，以允许多个网站工作。本地副本的根被设置为与subversion存储库的本地副本相同。这是设置好的，所以我们可以进行小调整，并立即预览它们。完成某些工作后，将向站点的存储库进行提交。我将自动推送开发站点（这是springloops中的一个选项）。然后，每当我觉得准备好推到客户端站点时，我都会这样做。最后一个阶段是推到现场

现在，我对这些工作流程有一些担忧：

我目前正在使用codeigniter，在配置文件中我通常设置站点的根目录。例。所以，看起来每次我发布到一个internet服务器时，我都必须修改配置文件？有没有办法使每个服务器都设置了某些文件？因此，当我点击publish to client preview时，它只是上传客户端预览服务器的配置文件

出于各种原因，我不希望live站点、客户端预览站点和开发站点共享同一个mysql服务器。那么，这是否再次意味着每次我推到不同的站点时都必须调整db服务器信息

这个工作流程有意义吗？如果你有任何建议，请告诉我。我计划这将是我在未来几年使用的工作流程。我只需要把一个系统在适当的地方，允许未来的扩展

1） 研究持续集成的概念。（对于小型项目CI服务器，例如TeamCity，有十几个免费项目）

2） 有一个。准备能够针对三种环境中任何一种环境的部署过程

3）考虑始终检查部署的位置上没有用户可以访问的.SNN文件，因为它确实是不安全的

另外，请阅读有关在SVN中使用标记/分支的内容

接下来，我将提出以下工作流程

第一个个案（简单） 每个人都进行结帐并在本地副本上工作。 在提交（经过良好测试）大量新功能后，您的触发器（可能会自动）预览将要构建 全面测试预览后，将触发建筑生产

第二种情况（更好） 每个人都会在每一个相当大的变化上创建一个分支，并且可以自由地将任何东西提交给自己的分支。 在分支稳定后，您将其合并到主干中，触发测试机器进行签出，并构建您命名的预览和标记 全面测试的预览将转到发布分支

---

拥有这么多分支的关键是能够同时存储个人更改历史记录和稳定版本。

对于分布式版本控制系统，有比subversion更好的版本控制解决方案，我强烈建议研究其中一种：

参见和，以了解一些不科学的讨论

---

同样，正如VITTROR所说的，我认为CI解决方案非常有用，可以将您的推送从DEV环境推到“生产”，客户机可以在成功的构建/测试周期上看到它。

< P>您不想使用存储库的根作为工作副本的根。这使得以后不可能真正使用分支。（或者你也可以让所有分支在本地签出..制作Subversion的廉价副本，工作副本的成本很高）

CI是否提供版本控制等？CI是顶级的东西。CI作为一个概念，包括版本控制的使用及其使用策略、测试、自动增量构建等CI服务器可以帮助您解决所有这些问题您认为CI可能会杀伤力过大吗？坦率地说，可能会，但我建议的是，至少要有明确的使用版本控制和自动构建过程的策略。rawr。刚刚花了几天时间熟悉subversion..：（是的，我知道，从这些阅读资料来看，这可能也是一种思维的转变。我正在考虑从TFSWell开始。罗兰要求的场景在这3个系统中一点也不容易。使用Subversion可以轻松地将所有当前可见的站点保存在一个工作副本中，而您将忙于合并来自联合开发的所有无关更改使用这些DVC的用户。没有支持稀疏工作副本、（混合修订版）部分更新的DVC。允许在服务器上共享单个工作副本。因此使用DVC需要使用不同的工作流。正如@David所回避的，分布式版本控制将继续存在：