在Subversion for Visual Studio项目中构造存储库的最佳方法?
我有一些C..dll`项目,这些项目对于许多应用程序是通用的。目前,我有一个大的存储库。我将每个DLL作为一个单独的项目存储在资源库中,并将每个应用程序项目作为一个项目存储在同一资源库中。
我最近切换到Subversion进行源代码控制,我担心在构建存储库方面做得不好。我想听听别人在做什么。
解决方案
回答
Subversion存储库通常细分为:
branch/ tags/ trunk/
我们可以将所有DLL和应用程序项目放入主干,然后根据需要对所有它们使用分支和标记:
branch/ tags/ trunk/ project1/ project2/
或者,我们可以在根目录中为每个项目创建文件夹,然后在其中放置公共分支,标签和主干文件夹。
project1/ branch/ tags/ trunk/ project2/ branch/ tags/ trunk/
请注意,这种做法只是约定俗成,而SVN中的任何操作都不需要(或者真正促进)完全以这种方式进行。但是,每个人都习惯了。因此,我们将为别人提供帮助。
为了进一步阐述,主干将是我们进行主要开发的地方。当我们要标记特定的修订版本(例如发行版本)时,只需svn将项目复制到标签目录中。另外,如果我们想做一些戏剧性或者长时间的操作而又不想阻碍主干的进度,则只需将代码复制到分支目录中即可。稍后,我们可以在准备好执行操作时,将其分支重新合并到svn中!
如果我们想纠正当前Subverion存储库中的故障,则只需使用svn move来重新定位它们。与CVS的删除和添加过程不同,move将保留新位置的版本历史记录。
回答
如果子项目可以以不同的版本发布(例如控件,Web部件等),那么构建这样的结构可能是有意义的:
解决方案
项目1
Branch Tags Trunk
项目二
Branch Tags Trunk
这样,我们可以独立管理每个项目版本。
否则,最常见的结构是:
Branch Tags Trunk Docs (Optional)
回答
使用branch / trunk / tag存储库结构是相当标准的,但是如果我对理解是正确的,那么问题就是我们拥有一组可以在多个项目中使用的常见dll项目。这肯定会变得棘手。
因此,这里的典型场景是我们拥有一个名为Common.Helpers的类库,该类库具有所有应用程序都通用的代码。
假设我正在启动一个名为StackOverflow.Web的新应用程序,该应用程序需要引用Common.Helpers。
通常,我们要做的是创建一个新的解决方案文件,并添加一个名为Stackoverflow.Web的新项目,并添加现有的Common.Helpers项目,然后从新的Stackoverflow.Web项目中引用它。
我通常尝试做的是为Common.Helpers项目创建一个存储库,然后在Subversion中将其作为外部引用。这样,我们可以将代码置于源代码控制下的单个位置,但仍可以在多个项目中单独使用它。
回答
我将所有内容存储在存储库中,以使开发人员(或者重建的devbox)可以轻松地从SVN检出,然后运行构建(所有必需的程序集都位于相对路径中)。如果我们有多个应分开的项目,这也将鼓励共享零部件的团队交付高质量的装配体。这可以遵循正常的生产思路,其中共享组件将在下游项目中更新。这是一个非常自然的软件价值链,但需要一点磁盘空间。
JP Boodhoo在自动构建,VS文件夹结构以及使开发人员快速启动和运行这一主题方面有一系列精彩的文章。
回答
感谢所有回答。 lomaxx,我花了整个上午研究使用外部功能,看来这是要走的路。我没有意识到,可能是因为它在Tortoise中并不十分突出。
回答
如果要同时在多个项目上使用Subversion 1.5的合并跟踪,则应使用一棵没有外部结构的树。
跟踪的合并(就像提交一样)总是在目录及其子目录上。
相同的规则适用于原子提交。 (仅在单个工作副本中稳定运行。它可能在某些其他特定情况下也有效,但不能保证这种行为)