You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Felix Brack <fb...@ltec.ch> on 2005/06/17 13:33:23 UTC
Re[2]: Setting head revision number
Hello Scott,
Well, it's just a one time problem: we delivered a software to our
customer with version 1.0.0.136 (it's in the printed documents of the
software). The last part of the version number (136) is always the
revision number of the repository at the point the software is
released, i.e. I create a tag 1.0.0.136 in the repository at revision
136. This is the way it normally should work.
The problem is (as I said, a one time problem) that I did not put the
software under subversion control, at the beginning of the development
(no time for setup, first project for subversion control, there are
many (or better no) excuses for this silly mistake).
Ok. The software was ready and I needed a version number. I called the
first release 1.0.0.136 with the idea of leaving some 'space' for other
revisions in the repository. That 'space' of revision numbers was
supposed to be 'filled up' quickly, so I could use revision number 136
to create the tag mentioned above. That idea was bad and silly and now
proves to be wrong; my repository is at revision number 86 instead of
being close to 136.
Now I do not want to change our tagging policy or the customers documents,
just because I was too lazy to put the project under subversion control
when we started it (this will _never_ever_ happen again!).
I am not quite sure if what I said makes any sense to you ...
Let me know if you see any other possibility to 'reverse' the mistake I
made. The 'for loop', as suggested by Marc was one of my first ideas,
but it will pollute the repository with meaningless revisions.
(there are days I definitely hate myself ...)
-------------------------
Felix
Scott Palmer wrote:
> On Jun 17, 2005, at 4:58 AM, Martin A. Brooks wrote:
>> Felix Brack wrote:
>>
>>> Let's say, my repository is at revision 85 now and I would like it
>>> to be
>>> at 136 instead of 86 after the next commit; how can I do this?
>>>
>>
>> You can't.
> More to the point, why would you want to?
> ---------------------------------------------------------------------
> 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
Re[2]: Setting head revision number
Posted by Felix Brack <fb...@ltec.ch>.
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
Re: Setting head revision number
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
Dirk Schenkewitz wrote:
> Then again, what keeps you from doing 'svn -cp PROJ-URL/ -r86
> URL/tags/1.0.0.136' -m "Release 1, named 1.0.0.136"' ? ;-)
That should read:
'svn -cp PROJ-URL/trunk -r86 PROJ-URL/tags/1.0.0.136' -m "Release 1, named 1.0.0.136"'
Sorry :-/
I better stop now and go home.
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting head revision number
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
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 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.
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
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.
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/1.0.0.136' -m "Release 1, named 1.0.0.136"' ? ;-)
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:
>>
>>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.
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
integer number.
> Good luck,
> Chris
Yes, good lock, er, luck :-)
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[4]: Setting head revision number
Posted by Scott Palmer <sc...@2connected.org>.
On Jun 17, 2005, at 11:08 AM, Christopher Ness wrote:
> You could always pad your repository
> with useless commits to get to the right version number. But that
> seems
> silly to me.
Yes, silly. But it is the simplest thing to do. 50 commits that
just change a comment to say "bumping to revision N to sync release
with number" aren't going to waste a ton of disk space or do anything
"bad".
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[6]: Setting head revision number
Posted by Felix Brack <fb...@ltec.ch>.
I'm very sorry; it was never my intention to start a discussion about
how different releases of a software should be numbered. Just for
clarification: we use the first three parts to identify the release
(major, minor, bugfix). The repositories revision number (call it
'build' or what you like) just gives a hint to the status of the
repository at the time the snapshot was taken.
In fact, the revision number is part of the tag since creating a tag
changes the repository's revision number. Of course everyone is free
to hide such information from customers.
-------------------------
Felix
Christopher Ness wrote:
CN> 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).
CN> Tags are much more powerful than revision numbers. Therefore I don't
CN> use revision numbers in my tag names.
CN> I prefer not to expose internal development revision numbers for just
CN> this reason. There is another thread that just finished up discussing
CN> revision numbers and reasons why not to depend on them (even in CVS!)
CN> Unclear: CVS and Subversion repository difference.
>> 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
CN> Gaining (or syncing with) revision control would be a good bug fix I
CN> think. ;)
CN> But it's a management decision. You could always pad your repository
CN> with useless commits to get to the right version number. But that seems
CN> silly to me.
CN> Good luck,
CN> Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[4]: Setting head revision number
Posted by Christopher Ness <ch...@nesser.org>.
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.
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.
> 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.
Good luck,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
11:00:38 up 1 day, 19:24, 2 users, load average: 0.00, 0.01, 0.03
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[4]: Setting head revision number
Posted by Felix Brack <fb...@ltec.ch>.
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).
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
-------------------------
Felix
Christopher Ness wrote:
CN> On Fri, 2005-06-17 at 15:33 +0200, Felix Brack wrote:
>> Hello Scott,
>>
>> Well, it's just a one time problem: we delivered a software to our
>> customer with version 1.0.0.136 (it's in the printed documents of the
>> software). The last part of the version number (136) is always the
>> revision number of the repository at the point the software is
>> released, i.e. I create a tag 1.0.0.136 in the repository at revision
>> 136. This is the way it normally should work.
>>
>> The problem is (as I said, a one time problem) that I did not put the
>> software under subversion control, at the beginning of the development
>> (no time for setup, first project for subversion control, there are
>> many (or better no) excuses for this silly mistake).
>>
>> Ok. The software was ready and I needed a version number. I called the
>> first release 1.0.0.136 with the idea of leaving some 'space' for other
CN> Try calling version two 1.0.1.86 ???
CN> Or does the 3rd vision number also have special meaning?
CN> Cheers,
CN> Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Setting head revision number
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-06-17 at 15:33 +0200, Felix Brack wrote:
> Hello Scott,
>
> Well, it's just a one time problem: we delivered a software to our
> customer with version 1.0.0.136 (it's in the printed documents of the
> software). The last part of the version number (136) is always the
> revision number of the repository at the point the software is
> released, i.e. I create a tag 1.0.0.136 in the repository at revision
> 136. This is the way it normally should work.
>
> The problem is (as I said, a one time problem) that I did not put the
> software under subversion control, at the beginning of the development
> (no time for setup, first project for subversion control, there are
> many (or better no) excuses for this silly mistake).
>
> Ok. The software was ready and I needed a version number. I called the
> first release 1.0.0.136 with the idea of leaving some 'space' for other
Try calling version two 1.0.1.86 ???
Or does the 3rd vision number also have special meaning?
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
10:20:49 up 1 day, 18:45, 2 users, load average: 1.16, 0.49, 0.23
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org