Hi Felix, Christopher,
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 18.104.22.168. I would
>>now like to create a tag 22.214.171.124 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.
That would be reasonable if you want to hide the svn-revnum from the
customers. as such it is a good idea, because the don't need to know
> 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.
I gained the opposite opinion from that thread.
Although the svn-revnum isn't useful to the customer, it may become
useful to the developer, namely for finding a specific revision.
Tags make a snapshot, but they are not related to the svn-revnum
anyhow (unless they are always be made from HEAD, in that case they
are always "svn-revnum + 1" of the revision you want to tag).
Then again, what keeps you from doing 'svn -cp PROJ-URL/ -r86
URL/tags/126.96.36.199' -m "Release 1, named 188.8.131.52"' ? ;-)
If you feel like, you could freely do the same for every internal
version that you care about, after all, copies are cheap. ;-P
(Just avoid checking out the /tags subdir as a whole, or you'll
get crazy ;-))
>>All parts of the version number have predefined meanings. In short:
>>| | | |_ 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.
I guess you're stuck with the loop solution if you want the svn-revnum
to be in sync with the last part of the release revision number. Anyway,
why not the doing so, all that is increased is a relatively meaningless
> Good luck,
Yes, good lock, er, luck :-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jun 17 18:51:50 2005