> At my previous employer, where spending money on tools didn't seem to be
> that big of an issue, we used ClearCase and we were able to mark all
> versions of a file at a certain stage belonging to a certain revision.
I am not sure what you are trying to say. Subversion 'versions' the
whole repository with a single revision/version number, say 12345.
Some of your files might be modified on revision 12340 and some in
12330 but at a given time your repository will have a single revision
where everything can be checked out for.
If you want to create a "version" out of your revision, you create a
tag (which is simply copying what you have into a new directory inside
the repository).
If you want to modify some sections of your code independent of
others, what you want to do is a branch. A branch can be a "version"
as well. When you have something ready to publish outside world, you
branch and mark your branch as "Release 1.18.4 of Product X", to take
your example.
For detailed information, please read chapter 4 of the book.
http://rush3d.com/reference/svnbook/ch04.html)
Subversion doesn't differentiate between the concept of tags (labels)
and branches and the cost to the backend is same. As a result if you
want to have further development/bug fixing on Release 1.18.4, you can
simply check out and start modifying.
If you are pretty certain that you are never going to start modifying
a release, you might even not branch and call your product "Release
1.18.4 build 12345" where 1.18.4 is the marketing-speak and your build
number is your repository version. On the other hand I strongly
suggest tagging/branching with each release. In my company we don't
have a fixed policy about branching and in some cases even when the
product gets released to the customer we just refer it with the build
version. On the other hand, a year later it becomes an issue
remembering what revision was the released product (We use Starteam at
work, not Subversion and it has no concept of repository-wide
revisions but it supports tagging (labels) which we use extensively
(actually we label the repository with each successful build, after QA
it might or might not get released)).
If you browse the Subversion repository
(http://svn.collab.net/repos/svn/) you will see a number of
directories:
Trunk: main development branch where you would assume everything is happening
Tags: A bunch of copies of Trunk where it is decided to have a "mark"
to define something happening, i.e., a release (1.0, 1.1, 1.2 etc.)
Branches: A bunco of copies of Trunk where something experimental is
going on (compared to the trunk directory) i.e., someone tinkering
with FSFS (http://svn.collab.net/repos/svn/branches/fs-enhancement-ideas/)
You can always see when a copy was done on different branches and
always find out which version of the file was used.
For example svn log
//svn.collab.net/repos/svn/Trunk/subversion/libsvn_fs/fs-loader.c will
give you all changes to this file. svn log
http://svn.collab.net/repos/svn/tags/1.2.0-rc1/subversion/libsvn_fs/fs-loader.c
on the other hand will show you that at revision 14019 someone
branched the trunk and created 1.2.0 release candidate 1 tag.
The main difference is, with clearcase and Starteam there is no
system-wide versioning. Hence you really want to know which version of
the file belongs to which branch/release. With Subversion, the whole
system is revisioned in one go and therefore given a revision number,
you have a version.
--
Hakan (m1fcj)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 24 19:19:31 2005