cwa*_*ole 7 svn version-control
这是我在过去一个月里遇到的两次,我甚至不确定如何将其称为Google查询.
我实际上正在使用SVN,但似乎这应该是一般的版本问题.
我们有两个项目,其中一个项目依赖于其他一些代码.由于API问题,在产品之间建立某种形式的链接并不务实(我不想配置所有非编码器的机器来完成这项工作).
我想如果我将共享代码的副本放入目录结构中,我将最终覆盖SVN使用的所有配置文件.这意味着依赖项目目录中的版本将无法再更新.
例如:
项目#1需要使用类MyExampleClass,但是,MyExampleClass被定义为Project#2的一部分并且需要它.
D.S*_*ley 14
我们已经svn:externals在实践中使用指向共享代码几年了.我们在使用它之前应该考虑一些有趣的问题.这是我们的结构:
root
+---common
| +---lib1
| | \---trunk
| | +---include
| | \---src
| \---lib2
| \---trunk
| +---include
| \---src
+---proj1
| \---trunk
| +---include
| | \---common
| \---src
| \---common
\---proj2
\---trunk
+---include
| \---common
\---src
\---common
Run Code Online (Sandbox Code Playgroud)
项目中和common目录中的目录都包含引入公共库的外部定义:includesrc
c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
svn:externals : lib1 http://.../common/lib1/trunk/src
lib2 http://.../common/lib2/trunk/src
Run Code Online (Sandbox Code Playgroud)
我们遇到的问题是多方面的,但与项目标记和分支有关,因为项目会随着时间的推移而变化.如果你想拥有可重现的构建,我上面展示的外部定义有一些非常严重的问题:
trunk.当你使用分支时svn copy,外部是逐字复制的,因为它们实际上只是附加到对象的属性.其他一些SVN命令(commit,checkout和export)实际上解释的性质.标记项目时,您确实希望始终保留项目的状态.这意味着您必须将外部"固定"到特定版本,因此您需要将外部定义更改为显式引用您想要的修订(例如,"lib1 -r42 http://.../common/lib1/trunk/src").这解决了问题的一个方面.
如果必须维护公共代码的多个不兼容分支,则必须明确指定(可能)修订版本所需的分支.
不用说,这可能有点令人头疼.幸运的是,有人在Subversion的土地上编写svncopy.pl脚本,自动化一些混乱.我们仍然(并且一直)在一个现场部署的产品中支持这一点的困难,这些产品具有一堆共享代码,并且在任何时候都可以在现场使用三种不同的版本.
如果您沿着这条路走下去,那么一定要考虑在项目发展和变化时如何维护这些联系.我们发现,在这里花一点时间考虑一个过程将会有很长的路要走.