Best practice for SVN tags?

问题

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?

回答1:

Do not forget that a tag and a branch are essentially the same thing in SVN: both are the result of svn copy

The trick is, since a tag represents a snapshot, it should be an "immutable" one, in that you should not make any modification on it.

What that snapshot (tag) represents is entirely up to you. it can be:

a stable state in the development
a mark just before a complicated merge (in order to go back to it if the merge is too complex to be resolved quickly)
a release or a patch
and so on...

回答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.

回答3:

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

回答4:

I prefer following structuring of my tags repository directory:

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

PA means pre-alpha A means alpha B means beta AR means alpha-release BR means beta-release RC means release candidate ST means stable

There are differences between builds and releases.

Tags under builds folder have version number corresponding to a pattern N.x.K, where N and K are integers. Examples: 1.x.0, 5.x.1, 10.x.33
Tags under releases folder have version number corresponding to a pattern N.M.K, where N, M and K are integers. Examples: 1.0.0, 5.3.1, 10.22.33.

Example of resulting structure of tags repository directory at some specific moment of time during repository structure evolution would be the following:

/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

Actually, this tagging principle is just a part of approach to repository structuring. You might find useful the diagram illustrating tagging principle I have described. Also it contains more complex overview of configuration management processes including branching and version numbering.

来源：https://stackoverflow.com/questions/372321/best-practice-for-svn-tags

标签

svn

version-control

collaboration