据我所了解，Subversion中的事务原则上应该支持此功能，但我不知道有哪些工具支持。背景是，我们正在讨论从PVCS Dimensions迁移到Subversion的问题，其中被引用为Subversion中缺失的主要功能是“设计部件”。设计部件是一组可以一起处理的任意文件集合，例如一个子项目所需的所有源文件。替代此功能的一个想法是在Makefile中进行复制操作，将相关文件复制到分支中。但如果所有文件都单独复制，则可能会导致大量修订版，这可能会使历史记录混乱，因此最好避免这种情况。编辑：一些背景信息：该项目由几个（5-10）子项目组成，这些子项目单独发布，但共享一些来自其他项目导入的公共源文件和外部库。设计部件的一个原因是限制对源文件的依赖性，另一个原因是管理子项目的产品，以便可以在一个操作中更新所有产品版本控制。这两种文件都分散在各个目录中。我们的团队有约5名开发人员。
Subversion：单个版本中是否可以执行多个复制操作？
7
- starblue
1
你的代码库结构是什么样子的？你试图通过复制一组文件来实现什么目标？ - basszero
8个回答
9
有一个名为svnmucc的工具可以实现这个功能，而且不需要使用工作副本：
http://subversion.tigris.org/tools_contrib.html#svnmucc_c
- Edmund
7
你可以使用：
svn copy FROM_URL1 FROM_URL2 URL_TO
例如：svn copy svn://192.168.1.50/trunk/folder1 svn://192.168.1.50/trunk/folder2 svn://192.168.1.50/tags/MY_TAG
- pmg
1
谢谢，它可以在没有工作副本的情况下运行。如果URL_TO不存在，则需要添加--parents标志以创建中间文件夹。 - gaelperret
6
您可以在工作副本中复制文件，并稍后一次性提交它们。这样只会创建一个版本。
使用命令行客户端时，可能如下所示：
svn copy file1 directory
svn copy file2 directory
svn copy file3 directory
svn commit
主要缺点是您需要一个工作副本，这个工作副本必须包含源目录和目标目录。
- Mnementh
2
不错，但是除非我检出一个工作副本到主干/分支之上，否则我需要两个版本，一个用于在工作副本中构建目录结构，另一个用于将其移动到正确位置。 - starblue
是的，但它可以运行。 :-) 这可能也表明，应该有一个工具能够做您想要的事情。 - Mnementh
3
这很有趣，我刚刚对设计部分进行了快速阅读。据我所知，通过将文件有效地分支到任意结构中，当您开始将它们合并回其原始位置时，您将会面临很多痛苦（并且合并可能不会在所有文件的单个提交中完成）。
但我认为您可以通过一些调整在Subversion中完成类似设计部分的事情：
首先，可以使用 externals（1.6 允许外部指向文件以及目录）来模拟设计部分。 要做到这一点，您可以设置项目层次结构如下：
每个零件文件夹只包含一个“svn:externals”属性，该属性将相应的文件引入到该部分的适当子位置中，例如：
您可以选择检出部分而不是trunk，以获取仅包含您想要文件且结构符合该部分定义的工作副本，提交时会直接进入trunk，无需合并。
您还可以通过首先创建trunk的分支（便宜快捷），然后将您的部分外部指针指向分支而不是主干来将您的部分基线化。这不会增加存储库的大小，您的工作副本保持完全相同的结构，只是从分支而不是trunk源所有文件。对该部分的任何更新也会针对该分支 -将更改合并到该部分只是将分支重新集成到trunk的标准svn实践。
管理部件的定义变得更有趣了，因为在上述方案中，每个部分都是手动定义的且它们不是分级的。您需要某种形式的脚本（例如makefile），该脚本知道部分层次结构并给定部分名称，可以构建适当的外部定义，然后应用于部分目录。
因此，尽管Subversion没有明确提供部分的抽象层，但可以手动模拟得非常准确-您只受svn:externals和您用于管理它们的脚本的能力限制。
但我认为您可以通过一些调整在Subversion中完成类似设计部分的事情：
首先，可以使用 externals（1.6 允许外部指向文件以及目录）来模拟设计部分。 要做到这一点，您可以设置项目层次结构如下：
/project1
/trunk
/doc
/design1
/release2
/src
/subproject1
/subproject2
/tags
/branches
/parts
/part1
/part2
/part3
每个零件文件夹只包含一个“svn:externals”属性，该属性将相应的文件引入到该部分的适当子位置中，例如：
svn:externals
../../trunk/src/subproject1 src/subproject1
../../trunk/doc/release2 doc/release2
您可以选择检出部分而不是trunk，以获取仅包含您想要文件且结构符合该部分定义的工作副本，提交时会直接进入trunk，无需合并。
您还可以通过首先创建trunk的分支（便宜快捷），然后将您的部分外部指针指向分支而不是主干来将您的部分基线化。这不会增加存储库的大小，您的工作副本保持完全相同的结构，只是从分支而不是trunk源所有文件。对该部分的任何更新也会针对该分支 -将更改合并到该部分只是将分支重新集成到trunk的标准svn实践。
管理部件的定义变得更有趣了，因为在上述方案中，每个部分都是手动定义的且它们不是分级的。您需要某种形式的脚本（例如makefile），该脚本知道部分层次结构并给定部分名称，可以构建适当的外部定义，然后应用于部分目录。
因此，尽管Subversion没有明确提供部分的抽象层，但可以手动模拟得非常准确-您只受svn:externals和您用于管理它们的脚本的能力限制。
- Jim T
3
谢谢，很有趣的信息。虽然我个人不太喜欢设计部分及其相关复杂性，但这可能有助于让其他人加入。 - starblue
关于合并回来，我的偏好是在发布之前只进行复制，以构建子项目。这将避免大部分或全部的合并回来。 - starblue
我对这个想法非常感兴趣。它为我之前在某些情况下推广的结构形式提供了正式化和理论框架。但是，对于这个问题，maven项目（或类似项目）是否更好，我还不确定。 - Jim T
0
为什么不把你的子项目放到自己的子目录中呢？
Project
|
---> Subproject 1
---> Subproject 2
Files from project.
通过这种方式，您可以始终在完整的子项目上操作。
这里我们有：
Project
|
---> common Files
---> Subprojects...
- boutta
1
实际上结构就是这样的，但有些人想要更精细的控制。 - starblue
0
你的工作流程/代码组织有误：
如果您在不同软件包之间有共享代码，那么这显然属于单独软件包中的一个。每个软件包有一个目录树。
将几个软件包（特定版本）放入某个环境中（例如由几个可能是可选的组件组成的较大软件产品）属于上面的单独层次：发行版，并由发行版的包管理基础设施处理。
如果您在不同软件包之间有共享代码，那么这显然属于单独软件包中的一个。每个软件包有一个目录树。
将几个软件包（特定版本）放入某个环境中（例如由几个可能是可选的组件组成的较大软件产品）属于上面的单独层次：发行版，并由发行版的包管理基础设施处理。
- Enrico 'nekrad' Weigelt
0
如果所有项目都在自己的存储库中，svn externals 可能会起到作用。
- basszero
0
我遇到了类似的问题：
如何将散布在存储库中的多个文件复制到标记中，并使其在一个事务中快速完成，从而形成一个修订版本。
最简单的方法是创建临时工作副本目录，将所有需要的文件复制到那里，然后将本地工作副本复制到远程存储库并删除临时目录：
svn mkdir TMP_DIR
svn mkdir TMP_DIR\MY_TAG
svn cp --parents src\test\File.txt TMP_DIR\MY_TAG\src\test\File.txt
svn cp --parents src\test2\File2.txt TMP_DIR\MY_TAG\src\test2\File2.txt
svn cp -m "comment" TMP_DIR\MY_TAG "http://myrepohost/myrepo/tags/"
svn rm --force TMP_DIR
希望这能有所帮助。
- Lukasz Wozniak
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接