SVN: Create a folder for old revisions_问答_开发者

I'm quite beginner with revision control systems so pardon me.

My project consists of two smaller applications, b开发者_开发知识库oth in their own SVN repositories. In addition, I have one repository shared (svn:externals) between those applications.

When a new version is released I would like to create a folder for that version (including sources, documents etc.). Repository for a single application should look something like this:

.UI
    . "old versions"
        . 1.0
        . 2.0
        . 2.5
    . trunk (current development version 3.0)

So my questions are:

What is the correct name for this kind of a structure (in SVN)?
How I can create it?
Is it possible to freeze those old revisions (prevent changes to that folder)?
Is there any better ways to achieve this?

"tags" is the standard and correct name for this folder.
"svn copy" is your friend for creating it. Many continuous integration products will have an option to automatically tag the builds.
Yes, you can freeze them with a "pre-commit hook" (see below.)
This is the standard way of doing things. If you deviate too far, you will confuse other users.

An example pre-comit hook (for windows) we use here:

@echo off
SET SVNLOOK=C:\Program Files\CollabNet Subversion Server\svnlook.exe
SET GREP=D:\SVN\REPO\hooks\grep.exe

REM Prevent changes to tags.
("%svnlook%" changed -t %2 %1 | "%grep%" "^U.*/tags/") && (echo Cannot commit an update to a tag.>&2 && exit 1)

REM Prevent commits without comments.
("%svnlook%" log -t %2 %1 | "%grep%" "[a-zA-Z0-9]") || (echo You must specify a comment for all actions.>&2 && exit 1)

exit 0

To manually create the tag, use a command like the following:

svn copy "http://your/repo/UI/trunk"  "http://your/repo/UI/tags/v3.0" -m "Tagging v3.0"

You should go through the first few chapters of the Subversion online reference over at http://svnbook.com. This will give you a quick and good start on both version control and Subversion.

What you're doing is pretty close to the way Subversion works. Do you have those directories yet?

In standard a Subversion setup, you setup a "tags", "branches", and "trunk" directory. Some people set these up on the root of their repository, others set them up under the root of each project.

For example:

svn://svn/trunk/proj1
svn://svn/trunk/proj2
svn://svn/branches/proj1/1.2
svn://svn/branches/proj2/3.4

svn://svn/proj1/trunk
svn://svn/proj2/trunk
svn://svn/proj1/branches/1.2
svn://svn/proj2/branches/3.4

Most sites I've seen do it the last way, but there can be advantages of doing it the first way (mainly due to using svn:externals and the fact when you do a checkout, your checkout isn't called trunk by default).

All you need to do is call your "old-versions" directory tags and you're all set:

svn://svn/UI/tags/1.0
svn://svn/UI/tags/2.0
svn://svn/UI/tags/2.5
svn://svn/UI/trunk

If you forgot to make the tag, panic ye not! One of the great things about Subversion is the revision number of the repository. It's sort of like making a tag every time you do a commit. If you can find the revision number when you did a release (usually through looking at the svn log) you can then copy that revision to create your tag:

$ svn cp -r1234 svn://svn/UI/trunk  svn://svn/UI/tags/2.0

As you can see, you use the svn cp command to create tags and branches. By the way, it's very easy to modify a tag without realizing it. In most sites, they have a pre-commit hook which either can prevent most users in making commits under the tags directory (this means you have to create the tags) or they allow users to create a tag (via svn cp) but not let users modify a tag once it is created. I have a Perl version of a pre-commit hook at http://dl.dropbox.com/u/433257/new_svn_hooks.zip if you want to take a look at it.

branches, tags and trunk
create the folders in your checkout and then commit them, then use "branch/tag" (tortoiseSVN) or "svn copy" for cmd line svn to create a tag of your trunk
you tag your trunk at a certain point e.g. v1, v2, v3 - this keeps a record of your repository at the current time and you can always go back to them
This is the way to achieve this

Branches are used for major changes that you should not do on the trunk (if you are working with a group of developers). You create a branch, merge trunk onto branch daily to avoid merge conflicts later on. Then when finished with the major change on the branch, you merge back onto trunk.

When you are ready for a release you create a tag of the whole trunk. Then release from there. If in the future you want to come back to a certain version then you have that historical reference in your tags. A tag just points to your repository at a certain point in time, e.g. rev 25123 when you trunk is at rev 35335 for example.