Ok, point taken... I've been trying to figure about how much that would
allow you to do and I did not really consider that the shear amount of data
required to reach that many commits would probably cause other problems
first.
Thanks to all.
----------------------------
.-. | Steven Velez
oo| | Software Engineer
/`'\ | alventive
(\_;/) | 678-202-2226
-----Original Message-----
From: Kirby C. Bohling [mailto:kbohling@birddog.com]
Sent: Friday, May 03, 2002 1:03 PM
To: Steven Velez
Cc: dev@subversion.tigris.org
Subject: Re: Multiple projects in one repository!
My former boss told me how to estimate how big 4.3 billion is. If you
did one commit every single second from Jan 1, 1970 to approximately
April 1, 2038 you'd use up half of the numbers (4.3billion is unsigned,
time_t's are signed). So considering the fact that every UNIX on the
planet is going to have a serious time issue in 2037-2038 that forces
them to move to better handling a 64-bit timestamp I wouldn't lose any
sleep over it.
After all that, just dump old revision numbers and re-import the project
into a new repository. If you have 4.3 billion revisions, you could
probably stand to dump more then handful of them. That or consider not
putting everything in a single repository. Even if all the CVS users in
the world were connected to a single repository you'd be hard pressed to
keep up that rate.
Any estimates on CVS users, say 500,000 of them, then 1 of every 6
can do
a single commit a day and not run the revision number out from 1970 to
2038. Have 60 repositories WORLD WIDE, and suddenly every one can do 10
commits a day and not run all of the repositories out of revisions oh
yeah, and you had to start in 1970 to run out before 2038.
Oh yeah, and I want your machine and net connection if it can keep up
with a commit a second. *grin*.
Kirby
Steven Velez wrote:
> The global repository revision has been something that I have never
> really been comfortable with since I started following subversion
> development. Some of it is because it's not what I'm used to but, more
> of it is it seems that it good gets too big fast. I mean, how is that
> revision number stored? Even if it's a unsigned 32 bit integer, I would
> not feel comfortable saying, "Well, you can make 4.3 billion separate
> commits to the repository and then you're hosed." It would be a bigger
> problem in bigger code-bases with more developers...... however, I'm
> sure this has already been considered and I'm just showing my ignorance
> but I would feel better to know the detail here in particular.
>
> ----------------------------
> .-. | Steven Velez
> oo| | Software Engineer
> /`'\ | alventive
> (\_;/) | 678-202-2226
>
>
>
>
>
>
> -----Original Message-----
> From: Bill Tutt [mailto:rassilon@lyra.org]
> Sent: Friday, May 03, 2002 12:19 PM
> To: 'Anders Hanson'; dev@subversion.tigris.org
> Subject: RE: RE: Multiple projects in one repository!
>
>
> You know, the revision number that's attached to the repository as a
> whole is meaningless from a user's perspective. It's an internal
> mechanism that accomplishes the goal of the underlying schema design. It
> just so happens to be exposed so that the user's interface can sometimes
> be a little more convenient to communicate numbers than obnoxious
> date/time strings.
>
> Repository revision number is only relevant to the repository, and user
> convenience. It has NO impact on any other factor of what you store in
> the repository. One repository has one revision number. This isn't
> likely to change. EVER. If it did, it would just make the schema
> unnecessarily complicated. If you don't like using the same revision
> number system for more than one project, either have more than one
> repository, or use date/time strings as the way to reference your
> project.
>
> Repository revision number bumps aren't nearly useful enough to be an
> accurate indication of the real rate of change of a given code base.
> There are other more complicated ways to get a much better picture of a
> code base's rate of change.
>
> Additionally, distributed replication systems commonly require a global
> repository revision number to indicate distinct points in time that
> contained a particular state, so the fact that Subversion has such a
> concept makes distributed repository replication easier to add on later.
>
> Bill
> ----
> Do you want a dangerous fugitive staying in your flat?
> No.
> Well, don't upset him and he'll be a nice fugitive staying in your flat.
>
>
> > -----Original Message-----
> > From: Anders Hanson [mailto:anders.hanson@speedo.nu]
> > Sent: Friday, May 03, 2002 9:08 AM
> > To: dev@subversion.tigris.org
> > Subject: RE: Multiple projects in one repository!
> >
> >
> > I know that Subversion doesn't care about the directory structure :)
> > What I meant was that it whould be nice if it was possible to have a
> > separate revision for each project. Right now you have to have one
> > repository for each project. Like i wrote in my first mail about this
> > when you're building products that are built of multible shared libs
> > it's not fun to have one repository for each library.
> >
> > Application 1 uses library 1, 2 and 3
> > Application 2 uses libraray 1, 3 and 4
> > Application 3 uses libraray 1
> >
> > It whould be nice if each library could be a separate "module" in the
> > repository, with it's own revision number, that is only bumped when
> > checking in that module.
> >
> > /Anders
> >
> > -----Original Message-----
> > From: sussman@collab.net [mailto:sussman@collab.net]
> > Sent: den 3 maj 2002 17:51
> > To: Anders Hanson
> > Cc: dev@subversion.tigris.org
> > Subject: Re: Multiple projects in one repository!
> >
> >
> > "Anders Hanson" <anders.hanson@speedo.nu> writes:
> >
> > > If it's possible it whould be nice to have a possibility to
> > > have multiple project's in one repository, and have on revision
> > > number for every project. Mostly to get rid of all the trunk/
> > > tags/ and branch/ directories (one for each proj) and instead
> > > have something like this
> > >
> > > repos/trunk/
> > > proj1/
> > > proj2/
> > > proj3
> > > repos/tags/
> > > proj1/
> > > 0.10
> > > repos/branches/
> > > proj2/
> > > 0.1
> > >
> > > instead of this
> > >
> > > proj1/trunk/
> > > src/
> > > include/
> > > tags/
> > > 0.10
> > >
> > > proj2/trunk/
> > > src/
> > > include/
> > > branches/
> > > 0.1
> >
> > You can lay your repository out however you want. Subversion doesn't
> > care.
> >
> > Because subversion's own repository has only one project, we chose the
> > latter layout. But if you want to put multiple projects in your
> > repository, then the former layout makes more sense, certainly.
> >
> > Subversion doesn't enforce any structure at all. You can lay out your
> > directories however you want. Or rearrange them later if you change
> > your mind.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
Received on Fri May 3 19:11:07 2002