Subversion、标记版本、共享库
我的团队即将发布一个版本，我们想在 subversion 中标记该版本。该版本 (v.1) 由多个应用程序组成，它们都引用共享库。 我读到组织主干/分支/标签的最常用方法是按项目进行。
问题#1：那么要使用这种结构发布版本，我是否必须单独标记每个项目？ 我的想法是，我可以创建多个级别的主干/分支/标签，一层位于根目录，一层用于每个项目。这将允许我为根主干的所有代码创建一个标签。
would look something like this:
/rep
/trunk
/office
/project1
/trunk
/branches
/tags
/project2
/trunk
/branches
/tags
/shared
/shared_project
/trunk
/branches
/tags
/tags
/branches
问题#2：如果我对 Q#1 的解决方案是一个坏主意，并且我必须为每个项目本身添加标签，那么如果我们后来在 v.1 中发现错误并需要进行修补程序，该怎么办？那么我是否必须再次手动将每个项目切换到 v.1 标签并将每个项目分支到开发分支？
编辑
感谢您的回答。我决定说服我的团队迁移到 Mercurial，这似乎是适合我们工作方式的 VCS。我也看过 git 但 hq 看起来更流畅。
My team is about to make a release, and we want to tag the release in subversion. The release (v.1) consists of several applications and they all reference shared libraries.
I'v read that the most commonly used way to organize trunk/branches/tags is to do it per project.
Question #1: So to make a release with this structure will I have to tags each and every project separately?
What I'm thinking is that I could create several levels of trunk/branches/tags, one in the root and one for each project. This would allow me to create a tag for all my code from the root trunk.
would look something like this:
/rep
/trunk
/office
/project1
/trunk
/branches
/tags
/project2
/trunk
/branches
/tags
/shared
/shared_project
/trunk
/branches
/tags
/tags
/branches
Question #2: If my solution to Q#1 is a bad idea and I have to tag each project for itself, what then, if we later find a bug in v.1 and need to make a hotfix. Do I then again have to manually switch each project to the v.1 tag and branch each of them to a development branch?
Edit
Thank you for your answers. I've decided that I'm gonna convince my team to move to Mercurial, seems like the right VCS for how we want to work. I've also looked at git but hq looks more smooth.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于所有项目都是独立版本的，单独标记每个项目将为您提供最大的灵活性。
如果您担心标记所有这些项目所需的工作量，您可以使用 svn 命令行客户端轻松完成此操作，
就像您在问题中所示的那样，嵌套最终将陷入无法维护的混乱之中。
示例
假设您的存储库位于
http://mysvn/上，具有以下布局：当您想要标记主干中的项目时，您可以从命令行运行以下命令。
结果是以下存储库布局
另一种方法假设您的存储库具有以下布局：
在这种情况下，您将使用以下命令进行标记：
这将使您的存储库处于以下状态：
就个人而言，我更喜欢第一种方法，因为它将文件夹保留在标签与主干中的标签处于同一级别，并且您最终不会得到一堆名为“v.1”的文件夹。归根结底，这是一个偏好问题。
Since all the projects are versioned independently, Tagging each project separately will give you the most flexibility.
If you are worried about the effort required to tag all these projects you can easily do this with the svn command line client
Nesting like you showed in your question will end up in an unmaintainable mess.
An example
Assume your repository is located on
http://mysvn/has the following layout:When you want to tag the projects from trunk you can run the following commands from the command line.
The result is the following repository layout
Another approach assumes your repository has the following layout:
In this case you will tag with the following commands:
This will put your repository in the following state:
Personally I prefer the first approach as it keeps the folders under tags on the same level as in trunk and you don't end up with a bunch of folders named "v.1". In the end it's a question of preference.
这个结构对我来说似乎是错误的：
为什么
/rep下面有一个trunk？应该是：接下来，您需要创建一个包含特定时间所有版本的标签。我建议创建一个包含其他项目的 ueberproject，例如
/rep/all/tag/1.0/office/project1使用
svn copy或使用svn 填充 ueberproject ：外部。前者像版本化文件系统一样使用 SVN：您可以创建要处理的文件的副本。
后者创建指向您需要的点滴的轻量级链接。在 SVN 中，这两种操作的成本大致相同（svn copy 还在内部创建了几个链接；它实际上并不复制任何内容！）
修复错误
如果您在 v1 中发现错误，您应该将项目导出到 DCVS，例如 Mercurial 或Git，在那里创建分支，修复错误。
与所有集中式 VCS 一样，SVN 并不擅长分支和合并。诚然，该操作在时间上并不像 CVS 那样昂贵，但从逻辑上讲，它是一团糟。
请参阅 http://hginit.com/ 了解为什么您不想从 Subversion 中的分支开始的详细说明。
如果您仍然想尝试，请阅读并理解以下内容： http://tortoisesvn .net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
This structure seems wrong to me:
Why is there a
trunkbelow/rep? It should be:Next, you need to create a tag which contains all the versions at a specific time. I suggest to create an ueberproject which contains the other projects like
/rep/all/tag/1.0/office/project1Fill the ueberproject with
svn copyor usingsvn:external.The former uses SVN like a versioned file system: You create copies of the files you want to work on.
The latter creates lightweight links to bits and pieces which you need. In SVN, both operations cost about the same (svn copy also creates a couple of links internally; it doesn't actually copy anything!)
Fixing bugs
If you find a bug in v1, you should export the project into a DCVS like Mercurial or Git, create branches there, fix the bug.
Like all centralized VCS, SVN isn't really good at branching and merging. Granted, the operation isn't as expensive time-wise as in, say, CVS, but logically, it's a mess.
See http://hginit.com/ for a longer explanation why you don't want to start with branches in Subversion.
If you still want to try, read and understand this: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
首先我要说的是，这里没有正确的答案（尽管有很多错误的答案）。
如果您将每个可部署项目放在单独的分支中，您最终可能会在尝试维护兼容内容的列表时遇到维护难题。我唯一提倡这样做的时候是，如果您正在谈论肯定会独立部署的完全独立的产品，例如创建多个不同应用程序、单独销售和独立版本控制的软件创建者。
如果这是内部的，那么管理一个存储库并将其作为一个整体进行分支/标记会容易得多。如果某个项目尚未更改，那么您不需要部署它 - 您要做的就是确保实时系统由存储库中的分支或标签表示。
对于共享库，您应该使用 SVN-externals - 将公共库存储在单独的程序集中，并使用 externals 将它们包含在构建中。
请注意，我有标签和分支 - 标签是指向与部署相对应的单个修订版的指针。分支从相应标记所在的位置开始，但如果您需要热修复生产系统，则可以在它们中放置代码修复。
因此，在回答 2）是的，如果您在 2 周前部署的 2.0 版本中存在错误，您需要切换到 R2.0 分支中工作，修复该错误，然后将修复合并回主干，以便它也将包含在未来的版本中。
就我个人而言，我在本地磁盘上维护多个分支，而不是使用我觉得令人困惑的 switch。
First let me say there is no right answer here (although there are lots of wrong ones).
If you put each deployable item in a separate branch you could end up with a maintenance headache trying to maintain a list of what's compatible with what. The only time I would advocate doing this is if you are talking about quite separate products that will be definitely deployed independently, e.g. a software creator that creates several different applications, sold individually and versioned independently.
If this is internal though, it's far easier to manage one repository and branch/tag it as an entirety. If an item has not been changed then you do not need to deploy it - all you try to do is make sure that the live system is represented by a branch or tag in the repository.
For the shared libraries you should use SVN-externals - store the common libraries in a separate assembly and use externals to include them in the the build.
Notice that I have tags and branches - the tags are pointers to a single revision that corresponds with a deployment. The branches begin where the corresponding tag does, but they are where you put code fixes in the event you need to hot-fix production systems.
So in answer to 2) yes, if you have a bug in Release 2.0 which was deployed 2 weeks ago, you need to switch to working in the R2.0 branch, fix the bug, then merge the fix back into trunk so that it gets included in future releases as well.
Personally I maintain several branches on my local disk rather than using switch which I find confusing.
这是我对你的问题的看法。
问题 1：您可以像以前一样为所有项目使用一个存储库。您可以在将每个项目部署到生产服务器上之前对其进行快照（标签），例如在 trunk/office/project1/tags 中标记project1版本
但是对我来说更正确的是该结构：
以这种方式，当您结帐主干时，您将得到一次放置项目的所有主干版本。
Q2。如果您在标签 v1 中发现错误，您需要从分支中的该标签切换或修复主干中的错误并在生产服务器上进行新部署以及新标签 - 这取决于您的开发周期。
here it is my opinion about your questions.
Q1: You can use one repository for all of your projects as you did. You can make snaptshots (tags) of each project before it's deployed on production server e.g. tag project1 version in trunk/office/project1/tags
However to me is more correctly that structure:
In tht way when you do checkout for the trunk you will get in once place all trunk version of your project.
Q2. If you find a bug in the tag v1 you need to switch from that tag in the branch or fix the bug in the trunk and make a new deploy on the production server plus new tag - this depends on your development cycle.