[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: revision numbering (was: Re: Multiple projects in one repository!)

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2002-05-04 07:20:52 CEST

Bill,

I've been trying to reproduce what you outlined in your last e-mail.
So I had four dirs in a repos

******
dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1
******
svn cp dir1 dir4 yields
svn up

dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1
dir4/dir1/file1
******
vim dir1/file1 and add line.
svn up

dir1/
dir1/file1 ** hass in fact changed as verified by a svn co to another
location
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1
dir4/dir1/file1 ** Still the same. A Tag right?
******
vim dir4/file1 add a line.
svn up

dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1 ** has the new content
dir4/dir1/file1 ** Still the same content as before
******
cd dir4
svn mv dir1 tag1wasdir1
svn ci

dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1 *** still has the new content
dir4/dir1/ *** empty in wc; but gone when svn up issued in anther location
*******what did I do wrong with my move?
dir4/tag1wasdir1/file1 ** *Still the same content as was in the now
renamed dir1 before
*******
rmdir dir4/dir1/
svn update

dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1 *** still has the new content
dir4/dir1/ *** this guys stays gone. Cool!
dir4/tag1wasdir1/file1 ** *Still the same content as before

*******
vim dir4/tag1wasdir1/file1 add a line.
svn update

dir1/
dir1/file1
dir2/bunch-o-files
dir3/bunch-o-files
dir4/file1
dir4/dir1/
dir4/tag1wasdir1/file1 HAs the new stuff This guy is now a branch right?
*******

So I assume that something is bad inside the FS based on what you guys are
saying.

ALSO:

Something else that confused me:

I was reading issues 653 and 654.

I must confess I got stuck on the first sentence of 654.
"Right now, we use a representation for NodeRevIDs which is unbounded in
length."

I'm still trying to figure out how NodeRevIDs have unbounded length.

So:
- "100" is a node id.
- "100.10" is a node revision id, referring to revision 10 of node 100.
- "100.10.3" is a node id, referring to the third branch based on
  revision 10 of node 100.
- "100.10.3.4" is a node revision id, referring to revision 4 of
  of the third branch from revision 10 of node 100.
And so on.

Does this notation continue on like 100.10.3.4.1.1?
In looking at some code I thought it could only be the 100.10 or the
100.10.3.4 case. I know I saw some code checking
for those two cases. I can't remember what for.

What am I missing here?

Thanks again.

gat

Bill Tutt wrote:

> It's ok to be confused, feel free to ask more questions!
>
> As some wise man once said: "Only fools fail to ask questions." :)
>
> 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 7:17 PM
> > To: Bill Tutt
> > Subject: Re: revision numbering (was: Re: Multiple projects in one
> > repository!)
> >
> > Bill,
> > Thanks for all your responses.
> > I've been reading 653 and 654. I have some major misunderstandings I
> > think. So I've been digging in more.
> > I'll post back as soon as I feel a little less clueless.
> > Thanks,
> > gat
> >
> > Bill Tutt wrote:
> >
> > > 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
Received on Sat May 4 07:17:27 2002

This is an archived mail posted to the Subversion Dev mailing list.