Svn Subversion：可以在一个版本中执行多个复制操作吗？

根据我对Subversion中事务的理解，原则上这应该是可能的，但我不知道有任何工具支持它

背景是我们正在讨论从PVCS维度到Subversion的迁移，Subversion中缺少的主要功能是“设计部分”。设计零件是可以一起处理的文件的任意集合，例如子项目所需的所有源文件

一种替代方法是在Makefile中执行复制操作，将相关文件复制到分支中。但是如果所有文件都单独复制，这可能会导致大量修改，这可能会扰乱历史，因此最好避免这种情况

编辑： 更多背景信息：

该项目由几个（5-10）子项目组成，这些子项目分别发布，但共享一些从其他项目导入的公共源文件和外部库

设计部分引用的一个原因是限制对源文件的依赖性， 另一个是管理子项目的产品，以便在一次操作中在版本控制中更新所有子项目。这两种文件在某种程度上都分散在不同的目录中

---

我们大约有5名开发人员参与该项目。

您可以在工作副本中制作副本，并在以后一次提交所有副本。这只会创建一个修订

使用命令行客户端时，它可能会如下所示：

svn copy file1 directory
svn copy file2 directory
svn copy file3 directory
svn commit

---

主要的缺点是您需要一个工作副本，而这个工作副本必须包括源目录和目标目录。

为什么不将您的子项目放到自己的子目录中呢

Project
   |
   ---> Subproject 1
   ---> Subproject 2
   Files from project.

通过这种方式，您可以始终对完整的子项目进行操作

我们有：

Project
   |
   ---> common Files
   ---> Subprojects...

---

如果所有项目都在其自己的存储库中，svn externals可能会执行此操作。

有一个工具svnmucc可以做到这一点，而不需要工作副本：

---

这相当有趣，我刚刚快速阅读了设计部分，从我收集的资料来看，通过有效地将文件分别分支到任意结构中，当您开始将内容合并回其原始位置时，您将面临一个痛苦的世界（合并可能不会在所有文件的一次提交中完成）

但我认为，在subversion中设计部件时，您也可以做类似的事情，只需稍加调整：

首先，可以使用externals模拟设计部件（1.6允许externals指向文件和目录）。 为此，您可以按如下方式设置项目继承权：

/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

然后签出部件，而不是主干，得到一个工作副本，其中只包含部件定义的结构中所需的文件，提交时，直接进入主干-此处不需要合并

您还可以通过首先对整个主干进行分支（既便宜又快捷）来基线化您的部分，然后将零件外部更改为指向分支而不是主干。这不会增加存储库的大小，并且工作副本保持完全相同的结构，您只是从分支而不是主干获取所有文件。对该零件的任何更新也会与分支相违背-合并存储库的更改该部分只是将分支重新集成到主干中的bog标准重新集成合并，这是标准的svn实践

管理部件的定义变得更有趣，因为在上面的方案中，每个部件都是手动定义的，它们不是层次结构。您需要某种形式的脚本（可能是makefile），它知道部件层次结构并给定部件名称，可以构建适当的外部定义，然后将其应用于部件目录

Project
   |
   ---> Subproject 1
   ---> Subproject 2
   Files from project.

---

因此，虽然subversion没有明确提供部件的抽象层，但它可以相当精确地手动建模-您只受svn:externals的功能和用于管理它们的脚本的限制。

您可以使用：

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

---

我也面临着类似的问题： 如何将分散在存储库中的多个文件复制到一个标记中，并使其在一个事务中快速运行，从而进行一次修订。 最简单的方法是创建临时工作副本目录，将所有需要的文件复制到该目录，然后将本地工作副本复制到远程存储库并删除临时目录：

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

---

希望能有所帮助。

您的工作流程/代码组织错误：

如果您在不同的包之间拥有共享代码，那么这显然属于 一个单独的。每个包一棵树

将几个（特定版本的）包放在一起到某个环境中 （例如，一个较大的软件产品，包括几个，可能是可选的， 组件）属于上面的一个单独的层：发行版，并被处理

---

通过发行版的包管理基础设施。

您的存储库结构是什么样子的？您通过复制周围的文件集试图实现什么？实际上，结构是这样的，但有些人希望更细粒度的控制。不错，除非我签出主干/分支上方的工作副本，否则我需要两个修订，一个用于在工作副本中构建一个目录结构，并将其移动到位。是的，但它可以工作。：-）可能它还表明，应该有一个工具，可以实现您的愿望。谢谢，有趣的信息。虽然我个人不太喜欢设计部分及其相关的复杂性，但这可能有助于让其他人加入。合并回来，我的首选方法是只在发布之前进行复制，然后构建子项目。这将避免大部分（如果不是全部的话）合并回来。事实上，我对这个想法很感兴趣。它为我以前在c中提出的结构形式化并提供了一个理论框架