I'm still struggling with this one myself. I understand your explaination
and I can accept it completely. I just want a way to be able to go to the
repository and get the svn revision that "is" release version XX.YYY of my
application. I don't want want to have to maintain a cross-reference list
independently of svn, and tagging seems to be problemmatic for TortoiseSVN
because it really slows down explorer with, for example, 6 projects and a
total of around 200 tagged revisions. So I thought maybe a label property
that manually gets set prior to commits of what would be release versions.
The problem with this is that there does not appear to be a way to determine
what is the revision number of a revision whoose label property has a value
of XX.YYY. Please help me out if I'm missing something... Maybe I'm
missing the most obvious solution here? Just put the release version string
in the commit message????
Thanks,
Wes
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Thursday, March 25, 2004 9:48 AM
To: bbeaudet@efficiencylab.com
Cc: users@subversion.tigris.org
Subject: Re: Repository Layout - One Vs. Many
"Brian Beaudet" <bbeaudet@efficiencylab.com> writes:
> The only thing preventing me from going with a single repository is
> the global revision number. If I start with one project and observe
> the number increasing sequentially, no problem. But when I add a new
> project and start where the last revision number left off (plus one of
> course) then it just seems strange. I was hoping to use the revision
> numbers in my application's version number (1.0.56 or
> 1.1.234) or something like that. How else does one keep track of that
> if not by the revision number?
This is a classic complaint of the global revision number. Many folks feel
better knowing that if they have revision M in their working copies, and
revision N is the latest, then exactly N - M changes to their project have
occured.
And the only response I can offer is that the change must occur within
yourself. People seem to think that an increasing revision number
demonstrates something -- anything -- about the state of their project. But
this is a kinda shaky place to stand. And if you ever,
*ever* use the changes in this number in a progress report to upper
management, you should be shot. :-)
That metric is an illusion -- three commits could contain { small change,
reversion of that change, different small change }. But a different single
commit could contain { entire re-write of the program }.
The numbers just don't matter. A project's own "version" should be managed
externally to the version control system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 25 17:08:32 2004