2009-07-13 119 views
3

我们必须使用标准的主干/分支/标签的结构保存在SVN主Visual Studio项目。但是,此项目引用此结构外部的外部项目,因此当我们创建代码分支时,所有对exteranl项目的引用都会失败,因为它们只有一个级别。最佳策略引用

即。行李箱/ MyProjectCode分支,所以由于层次的这种额外的水平,外部项目的任何引用失败后变得分支/ MyFeatureBranch/MyProjectCode。

什么是用尽可能少摩擦地创建新的分支,最好的办法?我可以写修改所有项目引用的脚本,或者我可以可以改变我的本地代码布局,使分支实际上水平从主干下来,等于是一个新的分支将是在同一水平上。任何其他建议/最佳实践?

+1

我看到你没有在这里接受答案,但想知道你是否对此进行了排序。我们有完全相同的问题,虽然我不想要数十个分支,但我们目前的解决方法意味着我们只能有一个让文件夹深度保持不变。 – DilbertDave 2009-12-03 10:21:08

回答

3

当从Subversion签出,你的工作目录没有反映同一目录深度在库中。例如使用目的的命令行:

svn co svn://server/project/trunk project 
svn co svn://server/project/branches/MyFeatureBranch project-feature

这样的话,你将有两个目录并排称为projectproject-feature。这应该避免不同目录深度和相对路径引用的问题。

+0

不确定我遵循:-s 因为我读到它,这仍然会导致分支中的项目功能比主干中的项目低一级。由于VS在.sln和.csproj文件中使用相对路径,所有引用等都会中断。 – DilbertDave 2009-12-03 10:24:27

1

我们分支,它涉及到产品的一切。因此,如果有5个项目是其中的一部分,我们将分支所有5个项目,以确保我们拥有该分支将要使用的完整副本。如果您遇到路径问题,您可能需要查看名为Junction的程序。

0

我在过去所做的那样,对于一个开发工作室开发的许多项目和许多共同的参考,是保持在共享位置的外部引用。这可能是网络共享,也可能是每个人在其硬盘驱动器上的商定(绝对)位置(结构像C:\ SharedLibs \ Library \ Version)。我们一直在sharedlibs在一个单独的svn存储库,每个人都必须检查到该文件夹​​SharedLibs,并建立我们引用这个绝对路径。

另一种策略我已经应用是什么,你还会发现在许多开源项目的:只是一起存储您的项目引用。例如。你可以有一个带有子文件夹src(用于源代码)和lib(用于外部引用)的主干。这可能是更好的做法:您只需构建项目(无论是中继还是分支)就可以检查并运行构建工具。

另一种选择是使用了svn:externals属性。通过此属性,可以确保将来自存储库中其他位置(或其他存储库)的文件与您的项目一起检出。从经验中,我不推荐这个,但它是一个选项。阅读关于它在svn书:http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html

0

我们在这里有同样的问题,我想过编辑.sln和.csproj文件替换绝对的相对路径。我是有点担心这样做,因为VS保持这些文件的,哪些是从撤消此,并在将来的某个时候(当一个开发保存项目,并检查它的实例)恢复到相对路径停止。

今天早上我有一个在我的上下班“清晰的时刻”:虽然我们存储在专用支路文件夹中的分支,为什么我要看看成一个?

所以,代替:

C: 
|_ svnworkarea 
     |_ project 
      |_ branches 
       |_ project-feature 
         |_ source etc 

      |_ trunk 
       |_ source etc 

我现在有:

C: 
|_ svnworkarea 
    |_ project 
     |_ project-feature 
       |_ source etc 

     |_ trunk 
       |_ source etc 

作为源文件夹现在在同一水平的相对路径是有效的,如预期的参考文献中加载。干线仍然是完全独立的,很容易识别,而项目特征由有意义的文件夹名称标识,例如, NewUIBranch。