svn：开发过程早期的模块组织
好的，我了解单个项目的存储库的主干/标签/分支。
现在假设我有一个主项目和一些较小的辅助模块/插件/工具/脚本等。在早期阶段有很多重命名、重组等，其中一些因为无处可去而早逝。在组织相当稳定之前，将特定模块插入后备箱对我来说是没有意义的。 （在这一点上，根据 svn 设计，复制到主干是“便宜的”）
在开发过程的早期放置小模块（例如“FooModule”）的最佳位置在哪里？
- /分支/开发/FooModule ？
- /开发/FooModule ？
- /sandbox/modules/FooModule ？
有人有以类似方式组织颠覆存储库的经验吗？什么对你有用？
OK, I understand the trunk/tags/branches thingy for a repository with a single project.
Now let's say I have a main project and a number of smaller auxiliary modules/ plugins / tools / scripts etc. During the early stages there's a lot of renaming, reorganization, etc., and some of them die an early death because they go nowhere. It doesn't make sense to me to stick a particular module into the trunk until the organization is pretty stable. (at which point copying to the trunk is "cheap" per the svn design)
Where would be the best place to put small a module (say "FooModule") early in its development process?
- /branches/development/FooModule ?
- /development/FooModule ?
- /sandbox/modules/FooModule ?
does anyone have experience organizing subversion repositories in a similar way? what has worked for you?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个非常有趣的问题，因为正确的开始有很多好处（模块化、低耦合......）。无论如何，这就是我开始的方式：
1）将所有内容放入主干：
2）如果可以的话，尽早开始将代码拆分为模块
3）如果模块稳定，将其上游移动到自己的存储库中：
4）最后，当您有多个稳定的模块和应用程序时，您最终可能会发现
每个应用程序/模块都有自己的发布周期。
或者，您可以看看 Spring 框架正在做什么（如果您问我的话，组织非常好）
我建议不要将代码拆分为每个模块的主干/分支，至少在项目开始时：当你开始分支（而不是在主干上工作）时，你不能再使用其他模块主干的 HEADS：你要么必须同时对所有项目进行分支，要么使用特定版本（1.0 而不是 SNAPSHOT）。我认为我不是很清楚，但如果我需要以不同的方式解释，请告诉我。
That's a very interesting question because starting right has a lot of benefits (modularization, low-coupling...). Anyway, this is how I would start:
1) put everything into the trunk:
2) if you can, start early to split the code into modules
3) if a module is stable, move it upstream into its own repository:
4) finally, when you have several stable modules and applications, you could end up with
each application/module having their own release cycle.
Alternatively, you can take a look at what the Spring Framework is doing (very nice organization if you ask me)
I would advise against splitting the code into trunk/branches for each module, at least at the beginning of the project: as soon as you start branching (and not working on the trunk), you cannot work with the HEADS of other modules' trunk anymore: you either have to branch all your projects at the same time or work with specific versions (1.0 and not SNAPSHOT). I don't think I'm very clear but let me know if I have to explain it differently.
当我自己处理这类事情时，我倾向于使用完全独立的存储库来避免主存储库因不必要的修改而变得混乱。
When I've approached this sort of thing myself I tend to use an entirely separate repository to save cluttering the main repository with unnecessary revisions.
恕我直言，如果您真的不想从一开始就将它放在主干中，那么
/branches/dev/FooModule将是最明智的方法。这就是开发分支的用途（除了通常情况相反，代码从那里的主干复制，然后最终返回到主干）。我肯定会避免使用不常见的根路径名，就像您给出的其他两个示例一样。您可以在 中找到更多注意事项使用 Subversion 进行版本控制。
The
/branches/dev/FooModulewould be the most sensible approach if you really don't want to have it in the trunk from the start IMHO. That's what development branches are for (except that normally that is the other way around, code is copied from the trunk there, then goes back to the trunk eventually).I would definitely avoid uncommon root pathnames like the two other examples you gave. You will find further considerations in Version Control with Subversion.
我喜欢为每个应用程序提供主干、标签和分支。在这样的设计中，您可以对沙箱做任何您想做的事情。
人们会就这种方式或根级主干、标签、分支方式的利弊来回争论，但这种方式的一个强大优点是合并和签出的痛苦要小得多。
（很多人忽视了这种结构，因为他们看到他们的项目在应用程序之间共享代码。当需要这种代码共享时，我们使用 svn:externals 取得了一些成功。这样做的真正好处是，即使对公共库进行重大更改也不会有问题如果您使用外部链接到标签，这将在已知可以工作的时候冻结公共库。）
I'm a fan of having trunk, tags, branches for each app. In such a design, you can kind of do whatever you want for a sandbox.
People will bicker back and forth about the pros and cons of doing it this way or the root level trunk, tags, branches way, but one strong advantage of this way is that merges and checkouts are much less painful.
(A lot of people overlook this structure because they see their projects sharing code between applications. We have some success using svn:externals when such code sharing is necessary. What's really nice about that is that even breaking changes to common libraries will be no problem if you use externals to link to tags, which will freeze the common library at a point when it was known to work.)
我不确定我的组织结构是否适合您的需求，但我采取了与主干/标签/分支模型非常不同的方法。看看 http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspx 了解详细信息。
这是我们的结构：
这里我们有以下根文件夹：
Trunk：这包含适合的最新代码修订版
融入主线。那里
是一个由所有人共享的主干
项目和团队。仅限开发者
必须签出这个文件夹
他们拥有所需的一切。
沙盒：这些是用于分支的个人开发区域
您想要的长期运行的更改
与行李箱保持分离，直到
他们已准备好合并回
后备箱。
暂存：这是最终的 QA/UAT 区域。 trunk复制到这里一次
发展被认为是稳定的
并准备好进行最终测试。这
保护发布免受开发影响
由其他团队提交给主干。
当版本处于此阶段时，您
不希望来自未知的提交
其他人进入您的代码库。
产品：这包含生产版本。每个应用程序都有其
prod 下有自己的文件夹
发行版有一个以
发布日期。分期
分支被复制到这些版本
部署时的标签，它们
表示代码的快照
释放时间。生产面积为
到底是什么的历史记录
发布时间和发布时间。
I'm not sure if my organization structure fits your needs but I took a very different approach than the trunk/tags/branches model. Take a look at http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspx for details.
Here is our structure:
Here we have the following root folders:
Trunk: This holds the latest code revisions suitable for
integration into the mainline. There
is a single trunk shared by all
projects and teams. Developers only
have to checkout this single folder
and they have everything they need.
Sandbox: These are personal development areas used for branching
long running changes that you want to
keep separate from the trunk until
they are ready to be merged back to
the trunk.
Staging: This is the final QA/UAT area. The trunk is copied here once
development is thought to be stable
and ready for final testing. This
protects the release from development
commited to the trunk by other teams.
When a release is in this stage, you
do not want unknown commits from
someone else entering your code base.
Prod: This contains production releases. Each application has its
own folder under prod and each
release has a folder named after the
date of its release. The staging
branch is copied to these release
tags upon deployment and they
represent a snapshot of the code at
the time of release. The prod area is
a historical record of exactly what
was released and when.
我无法编辑 David 的帖子，但我想提一下 svn:externals 的一些内容：从发布的角度来看，它们非常危险（imo）。这是噩梦般的场景：
让我们想象一下您的应用程序中有一些
svn:externals模块代码；为此，我们假设该模块的 Subversion 修订版为 1000。您创建一个分支，发布版本并将其发送给客户。时间流逝，几个月/几年后，客户要求您解决应用程序中的问题。您签出分支并启动
svn 更新项目。不幸的是，链接的模块已经发生了很大的变化，现在版本为 23456。现在应用程序甚至不再编译。当然，您必须做的就是在分支时更改 svm:externals 来指向确切的版本 (1000)。如果您必须更改模块的代码，那么您现在必须指向在修订版 1000 处为模块创建的分支的头部。
很多不必要的工作，这就是为什么我强烈建议不要在任何大型项目中使用外部代码项目。
如果您在 svn:externals 方面有过良好的经验，我会洗耳恭听。
I can't edit David's post but I want to mention something with
svn:externals: they are quite dangerous from a release point of view (imo). Here's the nightmare scenario:Let's imagine that you
svn:externalssome module code inside your application; for the sake of it, let's imagine that the Subversion revision is 1000 for the module. You create a branch, make a release and ship it to the customer.Time goes by and a couple of months/years later the customer asks you to fix a problem in the application. You check out the branch and start
svn updatingthe project. Unfortunately, the linked module has changed widely and has now the version 23456. And now the application doesn't even compile any more.Of course, what you have to do it so change the
svm:externalsto point the exact version (1000) when you branched. And if you have to change the module's code, than you have to point now to the head of the branch created for the module at the revision 1000.A lot of unnecessary work, that's why I would strongly discourage the usage of externals for any large project.
If you have had good experience with
svn:externalsI am all ears.