You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by kf...@collab.net on 2004/09/24 15:00:48 UTC
Re: A question on version numbers
Lee Butcher <le...@yahoo.co.uk> writes:
> Take this as the situation:
> 30 engineers, working on 200 files. Each engineer commits one file
> per day so
> there will be 30 commits in 1 day. That means the global version number will
> go from 0-30 in one day.
> The average project is 8 weeks which is 40 working days. At the end of the
> project the global version numner will be up to 1200.
> Have I understood the versioning system of Subversion correctly? Each commit
> increments the global version by 1?
> How high can this version number go?
You have understood global revisions correctly.
Internally, revision numbers are a typedef to 'long int'. That means
means in the very *worst* case you're safe for about 4 years at the
current rate. (C guarantees only 16 bits for 'long int', and in our
case it's a signed long int, so it's really 15 bits == 32768 maximum
revisions.)
However, the worst case is unrealistic. Modern C systems usually just
set 'long int' to the natural width of the processor, and I doubt
anyone's running Subversion on anything less than a 32-bit processor
today. That's a maximum revision of 2147483648, which would take
you... 265121 years to use up?
So I think you're okay.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A question on version numbers
Posted by Philip Martin <ph...@codematters.co.uk>.
Michael Sweet <mi...@easysw.com> writes:
> kfogel@collab.net wrote:
>> "Alexander L. Belikoff" <al...@belikoff.net> writes:
>>
>>>>You're right -- I just misread my ANSI C doc in a dumb way. A long
>>>>int is guaranteed to be at least 32 bits. Sorry for the confusion.
>>>
>>>Really?!?! I may be quite wrong, but AFAIR, the *only* thing ANSI C
>>>guarantees is that long int is *no less* in size than int (which, in
>>>turn is no less than short etc etc).
>> K&R (ANSI C) Second Edition, page 18, middle:
>> "long integers are at least 32 bits."
>
> IIRC, that K&R 2e book was released before the final ANSI C
> standard was ratified and isn't considered to be authoritative.
> (that isn't to say you aren't right, but just so you know...)
International Standard ISO/IEC 9899
5.2.4.2.1 Sizes of integer types <limits.h>
LONG_MAX 2147483647 // 2^31-1
A conforming implementation cannot use a smaller value.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question on version numbers
Posted by Michael Sweet <mi...@easysw.com>.
kfogel@collab.net wrote:
> "Alexander L. Belikoff" <al...@belikoff.net> writes:
>
>>>You're right -- I just misread my ANSI C doc in a dumb way. A long
>>>int is guaranteed to be at least 32 bits. Sorry for the confusion.
>>
>>Really?!?! I may be quite wrong, but AFAIR, the *only* thing ANSI C
>>guarantees is that long int is *no less* in size than int (which, in
>>turn is no less than short etc etc).
>
>
> K&R (ANSI C) Second Edition, page 18, middle:
>
> "long integers are at least 32 bits."
IIRC, that K&R 2e book was released before the final ANSI C
standard was ratified and isn't considered to be authoritative.
(that isn't to say you aren't right, but just so you know...)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question on version numbers
Posted by kf...@collab.net.
"Alexander L. Belikoff" <al...@belikoff.net> writes:
> > You're right -- I just misread my ANSI C doc in a dumb way. A long
> > int is guaranteed to be at least 32 bits. Sorry for the confusion.
>
> Really?!?! I may be quite wrong, but AFAIR, the *only* thing ANSI C
> guarantees is that long int is *no less* in size than int (which, in
> turn is no less than short etc etc).
K&R (ANSI C) Second Edition, page 18, middle:
"long integers are at least 32 bits."
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question on version numbers
Posted by "Alexander L. Belikoff" <al...@belikoff.net>.
On Friday 24 September 2004 11:19, kfogel@collab.net wrote:
> "Simon Large" <sl...@blazepoint.co.uk> writes:
> > I believe anything except extremely old C dialects guarantees that int is
> > at least 16 bits and long is at least 32 bits. Unfortunately I can't find
> > the official spec right now. 32 bit long was certainly widely used when
> > the PC was a 16 bit machine. Maybe if you are building SVN to run on an
> > 8-bit micro
>
> You're right -- I just misread my ANSI C doc in a dumb way. A long
> int is guaranteed to be at least 32 bits. Sorry for the confusion.
Really?!?! I may be quite wrong, but AFAIR, the *only* thing ANSI C guarantees
is that long int is *no less* in size than int (which, in turn is no less
than short etc etc).
I understand that it may not be an issue here as no one is going to support
SVN on CP/M maching running on Zylog 8080, but relying on certain long size
guarantees tends to bite someone in the a$$ especially when porting to 64 bit
architectures... ;-)
--
Alexander L. Belikoff
PGP/GPG fingerprint: 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701
(http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question on version numbers
Posted by kf...@collab.net.
"Simon Large" <sl...@blazepoint.co.uk> writes:
> I believe anything except extremely old C dialects guarantees that int is at
> least 16 bits and long is at least 32 bits. Unfortunately I can't find the
> official spec right now. 32 bit long was certainly widely used when the PC
> was a 16 bit machine. Maybe if you are building SVN to run on an 8-bit micro
You're right -- I just misread my ANSI C doc in a dumb way. A long
int is guaranteed to be at least 32 bits. Sorry for the confusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A question on version numbers
Posted by Simon Large <sl...@blazepoint.co.uk>.
<kf...@collab.net> writes:
> Internally, revision numbers are a typedef to 'long int'. That means
> means in the very *worst* case you're safe for about 4 years at the
> current rate. (C guarantees only 16 bits for 'long int', and in our
> case it's a signed long int, so it's really 15 bits == 32768 maximum
> revisions.)
I believe anything except extremely old C dialects guarantees that int is at
least 16 bits and long is at least 32 bits. Unfortunately I can't find the
official spec right now. 32 bit long was certainly widely used when the PC
was a 16 bit machine. Maybe if you are building SVN to run on an 8-bit micro
...
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org