我正在尝试为我们的Sage SalesLogix Web应用程序设置我的组织的源代码控制体系结构。我们正在使用SVN。
我们有3台服务器，一台用于开发，两台用于用户验收测试，两台用于生产。每个环境都有自己的数据库。
我们希望保持主干有序，但是当按照SalesLogix希望的方式管理VFS时，这可能会很困难。
我想做的是:-让所有开发人员在App Arch中使用SalesLogix的DEV安装实例将更改部署到本地机器进行本地单元测试和审查。-当所有开发工作完成后，在建议的修订中创建一个所有更改的包。一个构建管理器在UAT安装实例上安装包。-编译并部署到UAT文件夹。-如果拒绝，卸载bundle并在更改后重新安装。-在验收时，对生产服务器做同样的操作，并提交更改。
虽然这意味着我们有3个VFS，但这意味着我们只在一个VFS中开发，这对我来说是可行的。
我的思路正确吗?
老实说，我没有在SalesLogix模型中使用SVN，而是专门在SalesLogix中使用Git。这是因为Git的工作方式更适合SalesLogix和Application Architect的工作方式。在正常情况下，SCM并不重要，但它与SalesLogix有关。并不是说SVN不能很好地与SalesLogix模型一起工作，我知道有一些人将SVN与SLX一起使用(只是不像使用Git或Mercurial那么容易)，但老实说，抛开偏好不谈，SalesLogix VFS/模型实际上只与完全分布式的SCM一起工作。
也就是说，你描述的是我如何在Git中使用SalesLogix。我创建了一个开发分支，在那里做我所有的工作。master基本上反映了生产中的情况，因此如果需要，我可以随时从master重新部署到生产中。在开发分支中，我做所有的开发工作，也为特定的特性创建特性分支。然后在功能完成后进行合并。这种工作方式允许您在将所有内容移动到生产工作分支之前进行开发和测试。一旦准备好部署，我就可以轻松地切换到生产分支，然后从那里进行部署。如果QA拒绝了某些内容，那么只需切换回生产分支或回滚提交即可。此外，以这种方式工作，您实际上只需要一个VFS或模型。不是你所说的三个独立的分支，所有的东西都在独立的分支上，只有在完全开发和测试后才合并到主分支中。
尽管如此，我仍然保持独立的开发&从生产环境中测试系统(主要是因为我是作为SLX业务合作伙伴而不是SLX客户工作)，否则您就没有办法测试要交付的捆绑包。在开发系统中，我使用上面描述的分支来允许我在新功能开发仍在进行时将修复发布到生产中。
我希望我能为你提供更具体的SVN信息，但是无论使用哪种SCM，概念都是相同的。