Subversion：可以在单个修订中完成多个复制操作吗？
根据我对 Subversion 中事务的理解，原则上这应该是可能的，但我不知道有任何工具支持它。
背景是我们正在讨论从 PVCS Dimensions 迁移到 Subversion，而 Subversion 中缺少的主要功能是“设计部件”。 设计部分是可以一起处理的任意文件集合，例如子项目所需的所有源文件。
替换它的一个想法是通过 Makefile 中的复制操作，将相关文件复制到分支中。 但如果所有文件都单独复制，这可能会导致大量修改，这可能会扰乱历史记录，因此最好避免这种情况。
编辑： 更多背景信息：
该项目由几个（5-10）个子项目组成，这些子项目单独发布，但共享一些公共源文件和从其他项目导入的外部库。
设计部分引用的原因之一是限制对源文件的依赖， 另一个是管理子项目的产品，以便一次操作可以在版本控制中更新所有子项目的产品。 两种文件都或多或少地分散在目录中。
我们大约有 5 名开发人员参与该项目。
From what I understand about transactions in Subversion this should be possible in principle, but I don't know any tool that supports it.
The background is that we are discussing a migration from PVCS Dimensions to Subversion, and the main feature cited as missing in Subversion is "Design Parts". A design part is an arbitrary collection of files that can be handled together, e.g. all the source files needed for a subproject.
One idea to replace this is by copy operations in a Makefile, which copy the relevant files into a branch. But if all files are copied separately this may lead to a lot of revisions, which may clutter the history, so it would be nice to avoid that.
EDIT:
Some more background information:
The project consists of several (5-10) subprojects which are released separately, but which share some common source files and external libraries imported from other projects.
One reason cited for the design parts is restricting dependencies on source files,
another is for managing the products of subprojects, so that all of them can be updated in version control in one operation. Both kinds of files are somewhat sprinkled across directories.
We are about 5 developers on the project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
有一个工具 svnmucc 可以做到这一点，不需要工作副本：
http://subversion.tigris .org/tools_contrib.html#svnmucc_c
There is a tool svnmucc which does exactly this, without requiring a working copy:
http://subversion.tigris.org/tools_contrib.html#svnmucc_c
您可以使用：
svn copy FROM_URL1 FROM_URL2 URL_TO例如：
You can use:
svn copy FROM_URL1 FROM_URL2 URL_TOFor example:
您可以在工作副本中制作副本并稍后一次性提交它们。 这只会创建一个修订版。
使用命令行客户端，它可能看起来像这样：
主要缺点是您需要一个工作副本，并且该工作副本必须包含源目录和目标目录。
You can make the copies in a working-copy and commit them all at once later. That creates only one revision.
With the command-line-client it could look like that:
The main downside is you need a working-copy and this working-copy has to include source- and target-directory.
这相当有趣，我刚刚快速阅读了设计部分，根据我所收集的信息，通过有效地将文件单独分支为任意结构，当您开始时，您将走向一个痛苦的世界将内容合并回其原始位置（合并可能不会在所有文件的一次提交中完成）。
但我认为你可以做一些类似的事情来在 subversion 中设计部件，只需进行一些调整：
首先，可以使用外部来模拟设计部件（1.6 允许外部指向文件和目录）。
为此，您可以像这样设置项目层次结构：
每个部件文件夹仅包含一个“svn：externals”属性，该属性将该部件的适当文件引入适当的子位置，例如：
然后您签出该部件，而不是trunk，您将获得一个工作副本，其中仅包含该部分定义的结构中所需的文件，并且当您提交时，您将直接进入 trunk - 这里不需要合并。
您还可以通过首先对整个主干进行分支（便宜且快速）来确定部件的基线，然后更改部件的外部以指向分支而不是主干。 这不会增加存储库的大小，并且您的工作副本保持完全相同的结构，您只是从分支而不是主干获取所有文件。 对该部分的任何更新也会违背分支 - 合并该部分的更改只是将分支重新集成合并回主干的标准重新集成，这是标准的 svn 实践。
管理部件的定义变得更加有趣，因为在上面的方案中，每个部件都是手动定义的并且它们不是分层的。 您需要某种形式的脚本（可能是 makefile），它知道部件层次结构并给出部件名称，可以构建适当的外部定义，然后将其应用于部件目录。
因此，虽然 Subversion 没有明确提供部件的抽象层，但它可以相当准确地手动建模 - 您仅受 svn:externals 的功能以及用于管理它们的脚本的限制。
This is fairly interesting, I've just had a quick read on design parts, from what I can gather, by effectively branching the files individually into an arbitrary structure, you're going to be heading for a world of pain when you start to merge things back to their original location (and the merge probably won't be done in a single commit across all the files).
But I think you can do a similar thing to design parts in subversion with a bit of tweaking:
First, a design part can be simulated using externals (1.6 allows externals to point to files as well as directories).
To do this, you could setup your project heirarchy like this:
Each parts folder would only contain an "svn:externals" property which brings in the appropriate files for that part into the appropriate sublocation, like:
You then checkout the part, rather than trunk, and you get a working copy that contains just the files you want in the structure that the part defines, and when you commit, you're going straight into trunk - no merging required here.
You can also baseline your parts by first branching the entirety of trunk (cheap and quick), and then changing your part externals to point to the branch instead of the main trunk. This doesn't increase the size of the repository, and your working copy keeps exactly the same structure, you're just sourcing all your files from the branch rather than trunk. Any updates to that part also goes against the branch - merging the changes of the part is just a bog standard re-integration merge of the branch back into trunk, which is standard svn practice.
Managing the definition of parts gets more interesting, since in the scheme above, each part is defined manually and they're not hierarchical. You'd need some form of script (perhaps makefile) that knows the parts hierarchy and given a part name, can build the appropriate externals definitions which can then be applied to a parts directory.
So while subversion doesn't explicitly provide the abstraction layer of parts, it can be modeled manually fairly accurately - you're only limited by the capabilities of svn:externals and the scripts which you use to manage them.
为什么不将子项目放入自己的子目录中。
通过这种方式，您始终可以操作完整的子项目。
这里我们有：
Why don't you put your subproject into an own subdirectory.
In this way you could always operate on a complete subproject.
Here we have:
如果所有项目都在自己的存储库中，svn externals 可能会成功
If all projects were in their own repositories, svn externals may do the trick
我面临着类似的问题：
如何将分散在存储库中的多个文件复制到一个标签中，并使其在一次事务中快速完成，从而进行一次修订。
最简单的方法是创建临时工作副本目录，将所有需要的文件复制到那里，然后将本地工作副本复制到远程存储库并删除临时目录：
希望有所帮助。
I was facing similar problem:
how to copy several files, scattered in repository into a tag and make it fast in one transaction thus one revision.
Simplest way is to create temporary Working Copy directory, copy all needed files there and then copy local Working Copy to remote repository and remove temporary directory:
hope that helps.
您的工作流程/代码组织是错误的：
如果您在不同的包之间有共享代码，那么这显然属于
一个单独的。 每个包裹一棵树。
将多个（特定版本的）包放在一起放入某个环境中
（例如，一个更大的软件产品，由几个可能可选的、
组件）属于上面的一个单独的层：发行版，并且被处理
通过发行版的包管理基础设施。
Your workflow / code organisation is wrong:
if you've got shared code between separate packages, this clearly belongs into
a separate one. one tree per package.
putting several packages (of specific versions) together into some environment
(eg. a larger software product consisting of several, possibly optional,
components) belongs onto an separate layer above: the distro, and is handled
by the distro's package management infrastructure.