svn - Best practice for SVN tags?

Question

Should I use them as separate releases? Do I check them back into trunk or branches? Is this all in the red book and I've just wasted your time?

Answer 1

不要忘记标签和分支在 SVN 中本质上是相同的：两者都是svn copy

诀窍是，因为一个标签代表一个快照，它应该是一个“不可变”的，因为你不应该对它进行任何修改。

该快照（标签）代表什么完全取决于您。有可能：

• 发展中的稳定状态
• 复杂合并之前的标记（如果合并太复杂而无法快速解决，则返回到该标记）
• 发布或补丁
• 等等...

Answer 2

Not sure what you mean by "separate releases", but we copy from the trunk or branch we are making a build of into the tags folder with a descriptive name, like Proj-1.20.33

This way, for each build we have made, we can go back to that specific version. Generally, you would not want to make any real changes in a tag. For us, we go ahead and change some version numbers for the code and installer via our automated build process, so only those changes get merged back, and even then, that is the only thing that would be modifying those particular files.

The SVN Book talks about this a bit in Common Branching Patterns and the Tags entries.

Answer 3

Most people I know who are still on SVN tag their trunk (or current production branch) right before every release.

Answer 4

我更喜欢以下标签存储库目录的结构：

/tags
    /builds
        /PA
        /A
        /B
    /releases
        /AR
        /BR
        /RC
        /ST

PA表示pre-alpha A 表示alpha B 表示beta AR表示alpha-release BR表示beta-release RC表示候选版本 ST表示稳定

构建和发布之间存在差异。

• builds文件夹下的标签具有对应于模式的版本号N.x.K，其中N和K是整数。示例：1.x.0, 5.x.1,10.x.33
• 发布文件夹下的标签具有对应于模式的版本号，N.M.K其中和是整数。例子：, , .NMK1.0.05.3.110.22.33

tags在存储库结构演变过程中某个特定时刻生成的存储库目录结构示例如下：

/tags
    /builds
        /PA
            /1.x.0
            /1.x.1
        /A
            /1.x.2
        /B
            /1.x.3
            /1.x.4
    /releases
        /AR
            /1.0.0
            /1.1.0
        /BR
            /1.0.1
            /1.0.2
            /1.1.1
        /RC
            /1.0.3
            /1.1.2
        /ST
            /1.0.4
            /1.1.3

实际上，这种标记原则只是存储库结构方法的一部分。您可能会发现说明我描述的标记原理的图表很有用。它还包含更复杂的配置管理过程概述，包括分支和版本编号。