You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/05/03 17:32:39 UTC
revision numbering (was: Re: Multiple projects in one repository!)
On Fri, May 03, 2002 at 12:16:02PM -0500, Ben Collins-Sussman wrote:
> Well, that's kind of the point. Once we have a real SQL table or
> somesuch in our filesystem back end, then the revision "names" don't
> become so important. All revisions have datestamp properties attached
> to them. As long as we are always able to sort our revisions table by
> date, we'll have a well-ordered time machine. The revision names
> become irrelevant.
Actually, when we move to a SQL backend, I suspect that on some
implementations, we might end up with holes in the revision numbers. For
example, if we use an auto sequence to generate revision numbers *and*
transaction numbers, then you'll definitely have holes as most transactions
aren't actually committed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by Bill Tutt <ra...@lyra.org>.
It's ok actually. I certainly don't mind re-explaining this stuff. It's
very, very complicated.
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: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: Friday, May 03, 2002 3:57 PM
> To: Subversion Dev list
> Subject: Re: revision numbering (was: Re: Multiple projects in one
> repository!)
>
> Hey:
>
> I guess if I had actually subscribed to the issues list I would be
more on
> top of this.
> just subscribed.
> Sorry,
>
> gat
>
>
> ---------------------------------------------------------------------
> 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
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
I guess if I had actually subscribed to the issues list I would be more on top of this.
just subscribed.
Sorry,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Glenn A. Thompson" <gt...@cdr.net> writes:
> I wasn't paying close attention to the import/export thread. Does it lose
> NodeRevisionIDs?
Yes, it loses them -- creates new ones on import.
(And for those who weren't aware: The revision portion of a
"NodeRevisionID" has no relation to repository revision numbers. I
think we're going to call them "NodeChanges" after we take care of
http://subversion.tigris.org/issues/show_bug.cgi?id=654, to avoid this kind of confusion in the future.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by Bill Tutt <ra...@lyra.org>.
Somebody who has a more recent client bits of the SVN client bits should
feel free to check these PDFs in someplace in the tree.
And, yes, I did do these diagrams in Visio. The Visio bits that come
with Visual Studio Enterprise Architect to be specific.
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: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: Friday, May 03, 2002 3:34 PM
> To: Subversion Dev list
> Subject: Re: revision numbering (was: Re: Multiple projects in one
> repository!)
>
> Thanks for the response Bill.
>
> I will look at it right now.
>
> The ER diagram ...
> http://www.lyra.org/rassilon/SVNModel/SVNProjectv2.pdf
>
> Is this stuff going to be under Subversion Control at some point?
> I read all the txt files I can get my hand on. But pictures are
always
> useful.
> I say stuff because I went up a level and grabbed an older copy of
this
> and
> the SVNMODEL Diagrams. I believe they were done with Visio?
>
>
> gat
>
>
> Bill Tutt wrote:
>
> > NodeRevisionIDs as discussed in libsvn_fs/structure are changing
soon.
> > See http://subversion.tigris.org/issues/show_bug.cgi?id=654 for more
> > information as to why.
> >
> > The new way to identify "NodeRevisions" is by (NodeID,
TransactionID).
> >
> > NodeID is a monotonically increasing integer. However, due to the
> > funky-ness in O(1) copy support you aren't guaranteed to keep the
same
> > NodeID forever for a given path.
> >
> > Yes, this is odd, but SVN is very storage/time efficient for some of
> > it's operations and this causes interesting things to fall out in
the
> > data model.... :)
> >
> > Bill
> >
> > > -----Original Message-----
> > > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> > > Sent: Friday, May 03, 2002 12:18 PM
> > > To: Subversion Dev list
> > > Subject: Re: revision numbering (was: Re: Multiple projects in one
> > > repository!)
> > >
> > > Hey Guys:
> > >
> > > Isn't the real juice in the NodeRevisionIDs?
> > > Nodes are forever Right? Deleted for not they are forever Right?
> > > I guess I assumed, or (read and forgot; so now I assume), that in
> > terms of
> > > a
> > > unique identity to the world at large it would have to be
something
> > like
> > > "Unique ReposID".NodeRevisionID.
> > > I view the Revision number as something that can be reset at will.
> > The
> > > export
> > > import process does that right?
> > > I wasn't paying close attention to the import/export thread. Does
it
> > lose
> > > NodeRevisionIDs?
> > >
> > > I'm still spinning up, so go easy on me.
> > > FYI, I prefer to be beaten down with a wooden bat. No aluminum
please.
> > >
> > > Thanks,
> > > gat
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Thanks for the response Bill.
I will look at it right now.
The ER diagram ...
http://www.lyra.org/rassilon/SVNModel/SVNProjectv2.pdf
Is this stuff going to be under Subversion Control at some point?
I read all the txt files I can get my hand on. But pictures are always
useful.
I say stuff because I went up a level and grabbed an older copy of this and
the SVNMODEL Diagrams. I believe they were done with Visio?
gat
Bill Tutt wrote:
> NodeRevisionIDs as discussed in libsvn_fs/structure are changing soon.
> See http://subversion.tigris.org/issues/show_bug.cgi?id=654 for more
> information as to why.
>
> The new way to identify "NodeRevisions" is by (NodeID, TransactionID).
>
> NodeID is a monotonically increasing integer. However, due to the
> funky-ness in O(1) copy support you aren't guaranteed to keep the same
> NodeID forever for a given path.
>
> Yes, this is odd, but SVN is very storage/time efficient for some of
> it's operations and this causes interesting things to fall out in the
> data model.... :)
>
> Bill
>
> > -----Original Message-----
> > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> > Sent: Friday, May 03, 2002 12:18 PM
> > To: Subversion Dev list
> > Subject: Re: revision numbering (was: Re: Multiple projects in one
> > repository!)
> >
> > Hey Guys:
> >
> > Isn't the real juice in the NodeRevisionIDs?
> > Nodes are forever Right? Deleted for not they are forever Right?
> > I guess I assumed, or (read and forgot; so now I assume), that in
> terms of
> > a
> > unique identity to the world at large it would have to be something
> like
> > "Unique ReposID".NodeRevisionID.
> > I view the Revision number as something that can be reset at will.
> The
> > export
> > import process does that right?
> > I wasn't paying close attention to the import/export thread. Does it
> lose
> > NodeRevisionIDs?
> >
> > I'm still spinning up, so go easy on me.
> > FYI, I prefer to be beaten down with a wooden bat. No aluminum please.
> >
> > Thanks,
> > gat
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
RE: RE: Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by Bill Tutt <ra...@lyra.org>.
To add more detail in case it's not clear yet. Here's a snippet from IRC
that I hope helps clarify things.
<rassilon> copying foo to bar creates a new NodeID for Bar.
<rassilon> that's not the problem.
<rassilon> Copying foo to bar just copies foo.
<rassilon> All of the sub-things under foo aren't copied.
<rassilon> So foo/A and bar/A still point to the same NodeID,
ChangeSetID
<rassilon> pair
<rassilon> So when you have a change you're making to bar/A you just use
the existing NodeID, and everything is goodness.
<rassilon> (and the new CHangeSetID of course)
<rassilon> But when you then later change foo/A you have to notice that
the NodeID already has a later change on it then what you think it
should.
<rassilon> This means you need to assign yourself a new NodeID.
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: Bill Tutt [mailto:rassilon@lyra.org]
> Sent: Friday, May 03, 2002 2:08 PM
> To: 'Glenn A. Thompson'; Subversion Dev list
> Subject: RE: Re: revision numbering (was: Re: Multiple projects in one
> repository!)
>
> NodeRevisionIDs as discussed in libsvn_fs/structure are changing soon.
> See http://subversion.tigris.org/issues/show_bug.cgi?id=654 for more
> information as to why.
>
> The new way to identify "NodeRevisions" is by (NodeID, TransactionID).
>
> NodeID is a monotonically increasing integer. However, due to the
> funky-ness in O(1) copy support you aren't guaranteed to keep the same
> NodeID forever for a given path.
>
> Yes, this is odd, but SVN is very storage/time efficient for some of
> it's operations and this causes interesting things to fall out in the
> data model.... :)
>
> Bill
>
>
> > -----Original Message-----
> > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> > Sent: Friday, May 03, 2002 12:18 PM
> > To: Subversion Dev list
> > Subject: Re: revision numbering (was: Re: Multiple projects in one
> > repository!)
> >
> > Hey Guys:
> >
> > Isn't the real juice in the NodeRevisionIDs?
> > Nodes are forever Right? Deleted for not they are forever Right?
> > I guess I assumed, or (read and forgot; so now I assume), that in
> terms of
> > a
> > unique identity to the world at large it would have to be something
> like
> > "Unique ReposID".NodeRevisionID.
> > I view the Revision number as something that can be reset at will.
> The
> > export
> > import process does that right?
> > I wasn't paying close attention to the import/export thread. Does
it
> lose
> > NodeRevisionIDs?
> >
> > I'm still spinning up, so go easy on me.
> > FYI, I prefer to be beaten down with a wooden bat. No aluminum
please.
> >
> > Thanks,
> > gat
> >
> >
> >
> >
---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by Bill Tutt <ra...@lyra.org>.
NodeRevisionIDs as discussed in libsvn_fs/structure are changing soon.
See http://subversion.tigris.org/issues/show_bug.cgi?id=654 for more
information as to why.
The new way to identify "NodeRevisions" is by (NodeID, TransactionID).
NodeID is a monotonically increasing integer. However, due to the
funky-ness in O(1) copy support you aren't guaranteed to keep the same
NodeID forever for a given path.
Yes, this is odd, but SVN is very storage/time efficient for some of
it's operations and this causes interesting things to fall out in the
data model.... :)
Bill
> -----Original Message-----
> From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: Friday, May 03, 2002 12:18 PM
> To: Subversion Dev list
> Subject: Re: revision numbering (was: Re: Multiple projects in one
> repository!)
>
> Hey Guys:
>
> Isn't the real juice in the NodeRevisionIDs?
> Nodes are forever Right? Deleted for not they are forever Right?
> I guess I assumed, or (read and forgot; so now I assume), that in
terms of
> a
> unique identity to the world at large it would have to be something
like
> "Unique ReposID".NodeRevisionID.
> I view the Revision number as something that can be reset at will.
The
> export
> import process does that right?
> I wasn't paying close attention to the import/export thread. Does it
lose
> NodeRevisionIDs?
>
> I'm still spinning up, so go easy on me.
> FYI, I prefer to be beaten down with a wooden bat. No aluminum please.
>
> Thanks,
> gat
>
>
>
> ---------------------------------------------------------------------
> 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
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey Guys:
Isn't the real juice in the NodeRevisionIDs?
Nodes are forever Right? Deleted for not they are forever Right?
I guess I assumed, or (read and forgot; so now I assume), that in terms of a
unique identity to the world at large it would have to be something like
"Unique ReposID".NodeRevisionID.
I view the Revision number as something that can be reset at will. The export
import process does that right?
I wasn't paying close attention to the import/export thread. Does it lose
NodeRevisionIDs?
I'm still spinning up, so go easy on me.
FYI, I prefer to be beaten down with a wooden bat. No aluminum please.
Thanks,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
"Kirby C. Bohling" wrote:
> Glenn,
>
> If you have the proper amount of memory allocated, on the cache sequences
> you shouldn't lose any (you might have to pin them in memory). They
> only get lost if the sequence is forced out of the shared_pool (I think
> that is the name of it), or if the database crashes. We use to have
> problems with lots of skipping that I thought was a cache problem.
> Oracle Support beat me with a clue-by-4 when I insisted it was because
> they are cached.
Really? By memory do you mean bumping up some SGA related Parameter?
>
>
> You should only lose them if you ask for one and then either don't use
> it, or the transaction gets rolled back.
>
Yeah, I knew that.
>
> If you're really insistant on getting them in sequence it is in fact
> possible, but you completely serialize writting to the database, which
> is generally hell on performance.
>
Yeah! I assume you are speaking of the NOCACHE option.
I don't think insisting on them being in order is a good thing to do. Once you start
using a DB It seems that DBAs have a way of tuning something you never new existed.
>
> PostGres has similar problems, but MySQL for instance the auto-numbers
> in there I believe are always in order and all of them get used, (at
> least in the 3.X series), with the Table Level locking they do serialize
> the writes as a "feature".
>
Thanks for the input,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: revision numbering (was: Re: Multiple projects in one repository!)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Greg Stein wrote:
> On Fri, May 03, 2002 at 12:16:02PM -0500, Ben Collins-Sussman wrote:
> > Well, that's kind of the point. Once we have a real SQL table or
> > somesuch in our filesystem back end, then the revision "names" don't
> > become so important. All revisions have datestamp properties attached
> > to them. As long as we are always able to sort our revisions table by
> > date, we'll have a well-ordered time machine. The revision names
> > become irrelevant.
>
> Actually, when we move to a SQL backend, I suspect that on some
> implementations, we might end up with holes in the revision numbers. For
> example, if we use an auto sequence to generate revision numbers *and*
> transaction numbers, then you'll definitely have holes as most transactions
> aren't actually committed
Ahh Yes, and Oracle caches sequences. So you tend to lose some anyway.
>
>
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> 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