Dirk Schenkewitz wrote:
DS> Hi Felix, Christopher,
DS> Christopher Ness wrote:
>> On Fri, 2005-06-17 at 16:50 +0200, Felix Brack wrote:
>>
>>>I only have one release. Due to my laziness it's 1.0.0.136. I would
>>>now like to create a tag 1.0.0.136 in the repository that reflects the
>>>release running on the customers machine. If I tag now, the tags name
>>>(identifying the version number) would not correspond with the
>>>repositories revision number (which currently is 86).
>>
>>
>> Tags are much more powerful than revision numbers. Therefore I don't
>> use revision numbers in my tag names.
DS> That would be reasonable if you want to hide the svn-revnum from the
DS> customers. as such it is a good idea, because the don't need to know
DS> anyway.
>> I prefer not to expose internal development revision numbers for just
>> this reason. There is another thread that just finished up discussing
>> revision numbers and reasons why not to depend on them (even in CVS!)
>>
>> Unclear: CVS and Subversion repository difference.
DS> I gained the opposite opinion from that thread.
DS> Although the svn-revnum isn't useful to the customer, it may become
DS> useful to the developer, namely for finding a specific revision.
DS> Tags make a snapshot, but they are not related to the svn-revnum
DS> anyhow (unless they are always be made from HEAD, in that case they
DS> are always "svn-revnum + 1" of the revision you want to tag).
This is exactly the point. The tag or the snapshot get a label saying
'repository was at revision xyz when I was created'.
DS> Then again, what keeps you from doing 'svn -cp PROJ-URL/ -r86
DS> URL/tags/1.0.0.136' -m "Release 1, named 1.0.0.136"' ? ;-)
DS> If you feel like, you could freely do the same for every internal
DS> version that you care about, after all, copies are cheap. ;-P
DS> (Just avoid checking out the /tags subdir as a whole, or you'll
DS> get crazy ;-))
Imagine the following scenario: you have software product A and B in
the same repository. A and B use common files from a third part of the
same repository, let's call it L (for library, which is not exactly
what it is). L is just a bunch of source files. You never tag anything
in L since L is only used by A and B. A and B however are tagged
since there are different releases of them used by your customers.
If you look at the revision number of tag '1.0.0' of product A you can
immediately tell what files from L you used to build it.
In this scenario a version number containing the repository's revision
number (like '1.0.0.136' for product A) would be a good thing to have,
but only, if it's the correct one. Your command would have created a
copy named '1.0.0.136' which is not at all related to the repository's
revision number which is '86'. Now it would have been definitely better
to name the tag just '1.0.0' instead of '1.0.0.136'.
>>>All parts of the version number have predefined meanings. In short:
>>>
>>>1.0.0.136
>>>| | | |_ the repositories revision number
>>>| | |____ bugfix number
>>>| |______ minor number
>>>|________ major number
>>
>>
>> Gaining (or syncing with) revision control would be a good bug fix I
>> think. ;)
>>
>> But it's a management decision. You could always pad your repository
>> with useless commits to get to the right version number. But that seems
>> silly to me.
DS> I guess you're stuck with the loop solution if you want the svn-revnum
DS> to be in sync with the last part of the release revision number. Anyway,
DS> why not the doing so, all that is increased is a relatively meaningless
DS> integer number.
>> Good luck,
>> Chris
DS> Yes, good lock, er, luck :-)
DS> Dirk
DS> ---------------------------------------------------------------------
DS> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
DS> 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 Fri Jun 17 19:54:30 2005