[please keep this discussion on the list]
On Jun 17, 2005, at 11:17 AM, Dirk Schenkewitz wrote:
> Ben Collins-Sussman wrote:
>
>> On Jun 17, 2005, at 10:29 AM, ed.wittmann@fiserv.com wrote:
>> This is the key concept. A global repository revision has
>> absolutely nothing to do with the "version" of any project within
>> the repository. A project needs to invent its own release
>> numbering system and stick to it. A changing global repository
>> revision is just background noise, handles you can use to move
>> around in time, but totally unrelated to the software's maturity.
>> That's why svn, for example, has branches and tags named '1.1.x'
>> and '1.1.4'. *Those* are the only labels that matter.
>>
>
> One question: If someone wants a custom version with a feature that
> was
> built in after "1.1.3" and without another change that was done before
> "1.1.4", what is the best way to find the best svn-revnum to copy
> from?
> I know this is an artificial case since noone is expected to see a
> state between "1.1.3" and "1.1.4", but let's say a customer likes
> feature A and does not like feature B and we know that A had been
> introduced before B. Furthermore, I obviously forgot to tag "1.1.3-A"
> even though this was never planned to be released.
>
You run 'svn log' and find the commits for the bugfix or feature.
Then you 'backport' those specific revisions to a 1.1.3 working copy
(or a branch of 1.1.3).
There's a description of subversion's own release management process
in the book here:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4.1
The last step of the process is similar to what you're describing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 17 18:29:35 2005