[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Repository Layout - One Vs. Many

From: Crucius, Wesley <WCrucius_at_sandc.com>
Date: 2004-03-25 17:06:32 CET

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????


-----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

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

This is an archived mail posted to the Subversion Users mailing list.