Version Control with Subversion - Branch Maintenance - Data Lifetimes
Another nice feature of Subversion's model is that
branches and tags can have finite lifetimes, just like any
other versioned item. For example, suppose you eventually
finish all your work on your personal branch of the
calc project. After merging all of your
changes back into
no need for your private branch directory to stick around
$ svn delete https://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Removing obsolete branch of calc project."
Committed revision 375.
And now your branch is gone. Of course it's not really
gone: the directory is simply missing from the
HEAD revision, no longer distracting
anyone. If you use
to examine an earlier revision, you'll still be able to see
your old branch.
If browsing your deleted directory isn't enough, you can
always bring it back. Resurrecting data is very easy in
Subversion. If there's a deleted directory (or file) that
you'd like to bring back into
svn copy -r
to copy it from the old
$ svn copy -r 374 https://svn.example.com/repos/calc/branches/my-calc-branch \
Committed revision 376.
In our example, your personal branch had a relatively
short lifetime: you may have created it to fix a bug or
implement a new feature. When your task is done, so is the
branch. In software development, though, it's also common to
have two “main” branches running side-by-side for
very long periods. For example, suppose it's time to release
a stable version of the
calc project to the
public, and you know it's going to take a couple of months to
shake bugs out of the software. You don't want people to add
new features to the project, but you don't want to tell all
developers to stop programming either. So instead, you create
a “stable” branch of the software that won't
$ svn copy https://svn.example.com/repos/calc/trunk \
-m "Creating stable branch of calc project."
Committed revision 377.
And now developers are free to continue adding
cutting-edge (or experimental) features to
/calc/trunk, and you can declare a
project policy that only bug fixes are to be committed to
/calc/branches/stable-1.0. That is, as
people continue to work on the trunk, a human selectively
ports bug fixes over to the stable branch. Even after the
stable branch has shipped, you'll probably continue to
maintain the branch for a long time—that is, as long
as you continue to support that release for customers.
[an error occurred while processing this directive]