On Mon, Aug 1, 2011 at 1:06 PM, Robinson, Laura (IS) (Contr)
<Laura.Robinson_at_ngc.com> wrote:
> Can anyone tell me where the versioning numbers are set in the tool? Can
> you tell the tool how you want your numbers to start. For instance in
> Version Manager the first time you check in a file its version number is
> 1.0. If you modify the file and check it back in the version becomes 1.1
> and so on.
Hi, Like most, I came to SVN (and TortoiseSVN) from systems that used
numbers like 1.0 and 1.1 as you described. Andy mentioned that SVN
uses only a single number that increments with every commit to your
project repository. At first, this was a little confusing, but since
every project I've worked on gave each project its own repository,
this single number basically represents a project revision.
I soon came to like this single revision number as I could easily
compile this number into a project's final executable and be be able
to query the application for this number, then I can immediately
recall that revision of the whole project in to my workspace.
Another thing having a single project revision number makes easier is
locating when a problem first occured. If you experience a new problem
in your latest release, the numbers help you do a bisection search
through your revisions to determine in which revision the problem was
introduced. Then you can compare the changes in that revision from the
previous to look at the actual code changes so you have a better idea
of where to debug.
Also, SVN does provide for tagging (labeling) a specific revision with
a string like "Release 2.1 Beta 3" (or whatever other identifying
string you deem appropriate). Also, named branches can be created,
though since the revision number is for the whole project, commits to
a branch increment the revision the same way commits to the trunk do.
By the way,the $Revision$ keyword for files is still available (though
in SVN, keyword expansion is off by default), so you can still use
that, and it will refer to the revision where changes to that file
were last committed.
If you have process imposed constraints, SVN provides for hooks to
handle things like checking against process constraints or even
sending out email notifications. (SVN also provides per file locking,
though use of this feature is discouraged in favor of using a
copy-modify-merge workflow. This is explained the SVN book that Andy
mentioned: http://svnbook.red-bean.com)
Overall, I find SVN (and TortoiseSVN) a more developer-friendly
version control system. This is good because developers are then less
likely to devise ways to work around the system rather than with it.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2807818
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-08-01 21:44:15 CEST