提出SVN的版本控制策略
我要全天候尝试为公司制定版本控制策略。我们目前使用的是SVN，但没有结构-我们基本上只有一个主干，并且只能使用它。最近，开发经理启动了另一个存储库，它充当我们的“标签”，但是由于它不是同一存储库的一部分，而是完全独立的存储库，因此必须与“ trunk”手动合并。实际上，只有一个文件夹，称为“ Dev”（在不同的日期实际上有不同的“ Dev”文件夹，但只有“ Dev”是主要文件夹），在此之下还有其他所有文件夹。所有其他项目。它根本不是按项目组织的，它没有分支/标签/树干或其他任何概念。最初设置的人（已久，当然）似乎根本不知道如何设置SVN，从那以后，没有人会因为担心破坏某些东西而费心地学习如何正确地做事。我们不使用任何类型的CI（不幸的是，也不使用自动化测试）。 首先，我们应该按项目分开吗？例如，我们有：两个ASP.NET网站（非Web应用程序，网站），一个Web服务，一个用于所有表脚本和存储过程的部署文件夹，两个用于外部项目的命令行客户端，这些客户端由网站和具有公用业务对象等的共享文件夹。这些应该是属于自己的带有分支/标签/树干设置的项目，还是应该像这样： dev/ branches/ tags/ trunk/ Site1/ Site2/ WebService/ SharedCode/ 并具有所有分支，并且所有内容都具有整个Dev文件夹的副本？由于我们经常遇到需要在共享代码库和至少一个（通常是两个）网站中进行更改的情况，因此这种方法可能更容易被吞噬。 其次，我们定期向开发服务器和实时服务器发布（按我们的说法）。从我读过的最好的处理方式来看，所有开发都进入了trunk /，分支是“临时的”，用于添加可能影响主干的新功能，而标签用于发布？因此，我们每个月都在推动，我正在开发一个全新的模块。我将分支主干，并将该分支用于我的代码，编写和测试它以及其他内容。模块完成后，我会将其合并回主干（并可能删除分支），而当我们准备进行部署时，我们将对其进行标记（比如说“ May2011”）。如果我们在发布后进行了错误修复，则将在May2011标签中对其进行修复，然后将其合并到主干中（这样，主干也将获得此修复），然后May2011会因修复而再次推出？这是标记的意图吗？