处理多个颠覆项目之间的关系
在我的公司中，我们使用一个 SVN 存储库来保存我们的 C++ 代码。代码库由公共部分（基础设施和应用程序）和客户端项目（作为插件开发）组成。
存储库布局如下所示：
- 基础设施
- App1
- App2
- App3
- project-for-client-1
- App1-插件
- App2-插件
- 配置
- project-for-client-2
- App1-插件
- App2-插件
- 配置
客户端项目的典型版本包括项目数据及其使用的每个项目（例如基础设施）。
每个目录的实际布局是 -
- Infrastructure
- 分支机构
- 标签
- 树干
- -for-client-2
- 分支机构
- 标签
- 树干
其余项目也是如此。
上面的布局有几个问题：
- 很难为客户端项目启动一个新的开发环境，因为必须检查所有涉及的项目（例如：基础设施、App1、App2、project-for-client-1） 。
- 出于与上述相同的原因，很难在客户端项目中标记版本。
- 如果客户项目需要更改一些公共代码（例如基础设施），我们有时会使用分支。很难跟踪项目中使用了哪些分支。
SVN 有什么办法可以解决以上问题吗？我想过在客户端项目中使用 svn:externals ，但是在阅读 这篇文章 我知道这可能不是正确的选择。
In my company we are using one SVN repository to hold our C++ code. The code base is composed from a common part (infrastructure and applications), and client projects (developed as plugins).
The repository layout looks like this:
- Infrastructure
- App1
- App2
- App3
- project-for-client-1
- App1-plugin
- App2-plugin
- Configuration
- project-for-client-2
- App1-plugin
- App2-plugin
- Configuration
A typical release for a client project includes the project data and every project that is used by it (e.g. Infrastructure).
The actual layout of each directory is -
- Infrastructure
- branches
- tags
- trunk
- project-for-client-2
- branches
- tags
- trunk
And the same goes for the rest of the projects.
We have several problems with the layout above:
- It's hard to start a fresh development environment for a client project, since one has to checkout all of the involved projects (for example: Infrastructure, App1, App2, project-for-client-1).
- It's hard to tag a release in a client projects, for the same reason as above.
- In case a client project needs to change some common code (e.g. Infrastructure), we sometimes use a branch. It's hard to keep track which branches are used in projects.
Is there any way in SVN to solve any of the above? I thought of using svn:externals in the client projects, but after reading this post I understand it might not be right choice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以使用 svn:externals 来处理这个问题。这是 svn 存储库中某个位置的 url
这使您可以提取不同存储库（或同一存储库）的部分内容。使用它的一种方法是在project-for-client2下，您添加一个 svn:externals 链接到您需要的基础设施分支、您需要的app1分支等。因此，当您签出project-for-client2时，您会得到所有正确的部分。
svn:externals 链接与其他所有链接一起进行版本控制，因此当 project-for-client1 被标记、分支和更新时，正确的外部分支将始终被拉入。
You could handle this with svn:externals. This is the url to a spot in an svn repo
This lets you pull in parts of a different repository (or the same one). One way to use this is under project-for-client2, you add an svn:externals link to the branch of infrastructure you need, the branch of app1 you need, etc. So when you check out project-for-client2, you get all of the correct pieces.
The svn:externals links are versioned along with everything else, so as project-for-client1 get tagged, branched, and updated the correct external branches will always get pulled in.
建议更改
标记为
这种布局也存在一些问题。分支变得庞大，但至少可以更轻松地标记代码中的特定位置。
要使用代码，只需检查主干并使用它即可。那么您就不需要检查所有不同项目的脚本。他们只是用“../基础设施”来指代基础设施。这种布局的另一个问题是，如果您想完全独立地处理项目，则需要签出多个副本。否则，一个项目的基础结构的更改可能会导致另一个项目无法编译，直到该项目也更新为止。
这可能也会使发布变得更加麻烦，并分离不同项目的代码。
A suggestion is to change directory layout from
to
There are some problems with this layout too. Branches become massive, but at least it's easier to tag specific places in your code.
To work with the code, one would simply checkout the trunk and work with that. Then you don't need the scripts that check out all the different projects. They just refer to Infrastructure with "../Infrastructure". Another problem with this layout is that you need to checkout several copies if you want to work on projects completely independently. Otherwise a change in Infrastructure for one project might cause another project not to compile until that is updated too.
This might make releases a little more cumbersome too, and separating the code for different projects.
是的，这很糟糕。我们做同样的事情，但我真的想不出更好的布局。
所以，我们拥有的是一组脚本，可以自动化所有与颠覆相关的事情。每个客户的项目都将包含一个名为
project.list的文件，其中包含构建该客户所需的所有 Subversion 项目/路径。例如：每个脚本看起来像这样：
其中命令可能是结帐、更新或标记。它比这更复杂一些，但它确实意味着一切都是一致的，检查、更新和标记成为一个命令。
当然，我们会尝试尽可能少地分支，这是我能提出的最重要的建议。如果我们需要分支某些内容，我们将尝试使用主干或尽可能多的依赖项的先前标记版本。
Yeah, it sucks. We do the same thing, but I can't really think of a better layout.
So, what we have is a set of scripts that can automate everything subversion related. Each customer's project will contain a file called
project.list, which contains all of the subversion projects/paths needed to build that customer. For example:Each script then looks something like this:
Where the commands might be a checkout, update or tag. It is a bit more complicated than that, but it does mean that everything is consistent, checking out, updating and tagging becomes a single command.
And of course, we try to branch as little as possible, which is the most important suggestion I can possibly make. If we need to branch something, we will try to either work off of the trunk or the previously-tagged version of as many of the dependencies as possible.
首先，我不同意外在是邪恶的。尽管它们并不完美。
目前，您正在进行多次签出以构建工作副本。如果您使用外部设备，它就会完全执行此操作，但每次都会自动且一致。
如果您将外部指向目标项目中的标签（和/或特定修订），则只需标记每个版本的当前项目（因为该标签将准确指示您指向的外部）。您的项目中还会记录您更改外部引用以使用特定库的新版本的确切时间。
外部并不是万能的 - 正如帖子所示，可能存在问题。我确信有比外部更好的东西，但我还没有找到它（甚至在概念上）。当然，您使用的结构可以在您的开发过程中产生大量信息和控制，使用外部可以增加这一点。然而，他遇到的问题并不是根本性的腐败问题——一次干净的获取就能解决所有问题，而且这种情况非常罕见（你真的无法在你的存储库中创建一个新的库分支吗？）。
需要考虑的要点 - 使用递归外部。我不认同这一点，而是倾向于采取务实的态度。
考虑使用文章建议的活塞，我还没有看到它的实际应用，所以无法真正发表评论，它可能会以更好的方式完成与外部组件相同的工作。
First, I don't agree that externals are evil. Although they aren't perfect.
At the moment you're doing multiple checkouts to build up a working copy. If you used externals it would do exactly this, but automatically and consistently each time.
If you point your externals to tags (and or specific revisions) within the target projects, you only need to tag the current project per release (as that tag would indicate exactly what external you were pointing to). You'd also have a record within your project of exactly when you changed your externals references to use a new version of a particular library.
Externals aren't a panacea - and as the post shows there can be problems. I'm sure there's something better than externals, but I haven't found it yet (even conceptually). Certainly, the structure you're using can yield a great deal of information and control in your development process, using externals can add to that. However, the problems he had weren't fundamental corruption issues - a clean get would resolve everything, and are pretty rare (are you really unable to create a new branch of a library in your repo?).
Points to consider - using recursive externals. I'm not sold on either the yes or no of this and tend to go with a pragmatic approach.
Consider using piston as the article suggests, I've not seen it in action so can't really comment, it may do the same job as externals in a better way.
根据我的经验，我认为为每个单独的项目建立一个存储库会更有用。否则，您会遇到您所说的问题，而且，如果其他项目发生变化，修订号也会发生变化，这可能会造成混乱。
仅当各个项目之间存在关系时，例如软件、硬件原理图、文档等。我们使用单个存储库，因此修订号可以使整个包达到已知状态。
From my experience I think it's more useful to have a repository for each individual project. Otherwise you have the problems you say and furthermore, revision numbers change if other projects change which could be confusing.
Only when there's a relation between individual projects, such as software, hardware schematics, documentation, etc. We use a single repository so the revision number serves to get the whole pack to a known state.