blocks|key|1176033|text|SVN提供标记，用于在特定时间(可以用于发布等)获取源树的“时间快照”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1176034|但是，如果您打算使您的存储库“更加细化”，也许您应该考虑建立多个存储库。|1176035|当然，在“主干”文件夹中，如果不使用源代码控制，您应该设置任何正常的目录层次结构。|1176036|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

SVN provides tags to take a 'snapshot in time' of the source tree at a particular time (which you can use for releases, etc.).

But if you're intending to make your repository 'more granulated', maybe you should consider setting up multiple repositories.

Of course, within the 'trunk' folder, you should set up whatever normal directory hierarchy you would if you didn't use source-code control.

blocks|key|2700577|text|我们也一直在胡思乱想。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2700578|我们已经发现，在某些共享库成为多个应用程序的一部分之前，不需要很长时间，您可能希望将所有内容都放在同一个版本上。因此，我们决定将我们所做的一切放在一个存储库中。我们已经这样工作了两年多了，并发现这是非常好的工作。|2700579|所有配置都有pro和con，但是通过拥有一个完整的存储库，您可以(几乎)确定所有文件都在正确的版本上。如果您使用多个主干，可以使用虚拟文件夹或链接(我已经忘记了这个术语)来使其彼此链接，但回到原来的状态是非常困难的。|2700580|请记住，每个配置都有pro和con，但是对于一个不太大的公司，我建议把所有的东西都放在一个只有一个父文件夹的回购中。|2700581|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

We've been strugling with this too. 

We've found out that it doesn't take long until some shared libraries are part of multiple applications and you would want to have everything on the same version. Therefore we've decided to put everything we do in one single repostitory. We've been working this way for over 2 years now and find it very good to work with.

All configurations have pro's and con's but by having 1 full repository you can be (almost) sure that you have all files together at the right version. If you work with multiple trunk's there are tricks with virtual folders or links (I've forgotten the term) to make it link with each other, but getting back to the point where you were is very hard. 

Just remember each config has pro's and con's, but for a not to large company I would suggest to put everything in a single repo with one parent folder.

blocks|key|2700649|text|我们从一个类似的模型开始，但发现它有点麻烦。主要的问题是，如果您想在发行版中分支代码库，就必须为每个组件创建分支。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2700650|相反，我们考虑了如下方案：|2700651|++trunk
++++app1
++++app2
++++lib1
++++lib2
++branches
++++rc-2.0
++++++app1,+app2,+lib1,+lib2...
++++some-devs-branch
++++++app1,+lib2
++tags
++++release-1.0
++++++app1,+app2,+lib1,+lib2...|code-block|syntax|javascript|2700652|我喜欢一个单独的回购完全为第三方的东西。除非您计划从供应商分支策略实现完整的红豆书，否则这将很好地工作。|offset|length|2700653|entityMap|0|LINK|mutability|MUTABLE|url|http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html|1|http://svnbook.red-bean.com/^0|0|0|0|Q|7|0|12|3|1|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@$K|10|L|11|1|12]|$K|13|L|14|1|15]]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]|U|$5|P|Q|R|A|$S|V]]]]

We started with a similar model, but found it to be a bit cumbersome. The main problem is that if you want to branch your codebase at a release, you have to go make branches for each component.

Instead, we've considered a scheme like the following:

<pre><code> trunk
 app1
 app2
 lib1
 lib2
 branches
 rc-2.0
 app1, app2, lib1, lib2...
 some-devs-branch
 app1, lib2
 tags
 release-1.0
 app1, app2, lib1, lib2...
</code></pre>

I like having a separate repo entirely for 3rd-party stuff. Unless you plan to implement the full <a href="http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html" rel="noreferrer">vendor-branching strategy</a> from the <a href="http://svnbook.red-bean.com/" rel="noreferrer">red bean book</a>, this will work well.

blocks|key|1118216|text|我目前的方法是打破逻辑应用程序边界上的系统，所有这些都位于一个存储库中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1118217|例如，设想一个服务也具有测试套件和数据库。|1118218|/project1/application1/
++++++++++++++++++++++trunk/
++++++++++++++++++++++++++++Src
++++++++++++++++++++++++++++Test
++++++++++++++++++++++++++++Database
++++++++++++++++++++++tags/
++++++++++++++++++++++branches/
+++++++++application2/
++++++++++++++++++++++trunk/
++++++++++++++++++++++++++++Src
++++++++++++++++++++++++++++Test
++++++++++++++++++++++tags/
++++++++++++++++++++++branches/+++++++++++++++++++++++|code-block|syntax|javascript|1118219|这允许我们使用一个项目来处理多个应用程序，但是可以处理每个“逻辑”应用程序边界的发布控制。考虑您的发布控制需要在哪里/什么位置，并将其设置为分支/标记/主干结构的位置。|1118220|我不喜欢位于整个存储库根目录下的单个主干/分支/标记文件夹，因为我不想让整个主干签出，也不想因此而破坏部分分支签出。(你可能不同意，你的里程可能会变化等等)|1118221|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

My current approach is breaking the systems on logical application boundaries all under one repository.

For example, imagine a service that also has a test suite and a database

<pre><code>/project1/application1/
 trunk/
 Src
 Test
 Database
 tags/
 branches/
 application2/
 trunk/
 Src
 Test
 tags/
 branches/ 
</code></pre>

This Allows us to have multiple applications assoicated with a project, but handle release control for each "logical" application boundary. Consider where/what your release control need are and set those as the location of the branch/tag/trunk structure.

I don't like the single trunk/branches/tags folder at the root of the entire repository, because I don't want to have the entire trunk checked out, nor do I want to mess with partial branch checkouts as a result. (You may disagree and your mileage may vary etc etc)

blocks|key|1118695|text|我们总是为每个单独的“解决方案”创建一个单独的SVN存储库。然后，这个存储库只有一个简单的主干、分支和标记结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1118696|任何依赖的框架(我们控制源代码的地方)都有自己独立的存储库。然后，我们通常只将二进制文件(在特定版本中)包含到使用它们的任何项目中。|1118697|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We always create a separate SVN repository for each separate "solution". This repository then just has a simple trunk, branches and tags structure.

Any dependent frameworks (where we control source code) then have their own separate repository. We typically then just include binaries (at a particular version) into any project using them.

blocks|key|2700798|text|每件事都有一个回购，这意味着你很有可能很快就拥有一个庞大的存储库。这意味着事情会变得缓慢，也会有点难以追踪。显然，这取决于您的确切用例，但就我个人而言，我会选择每个项目的存储库，并在需要的地方使用svn:externals。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2700799|实际上，如果可能的话，我会在SVN上选择一个分布式VCS，但是每个人都有自己的.|2700800|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Having a single repo for everything means that you have a pretty good chance of ending up with a huge repository pretty fast. Which means things can get slow and a bit hard to track as well. Obviously, it depends on your exact use case, but personally I'd opt for per-project repositories and using svn:externals where needed. 

Actually, I'd opt for a distributed VCS over SVN if possible, but to each his own...

I am getting ready to set up an SVN repository, and was wondering if anyone had a good example for a repo structure. I am currently thinking:

<blockquote>
 Development 
 .. Applications 
 .... App1 
 ...... trunk 
 ...... branches 
 ...... tags 
 .. Database 
 .. Third Party
</blockquote>

While this structure could probably hold everything we need, I would like to make it a bit more granulated. Any thoughts?

SVN Repository Structure

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在准备建立一个SVN存储库，并且想知道是否有人有一个回购结构的好例子。我目前在想：开发。。应用程序……App1.中继线.分支.标签。。数据库。。第三方虽然这个结构可以容纳我们所需要的一切，但我想让它变得更细一些。有什么想法吗？

问SVN存储库结构
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN存储库结构EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN存储库结构
EN