You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2000/11/27 21:53:05 UTC
Re: Some filesystem questions
Jim Blandy wrote:
>> Is the ENTRY the same in both cases? And in DIR, if I'm
>> right, ENTRIES can be empty -- but "skel.h" doesn't allow an
>> empty list.
>
>
> No, ENTRY isn't the same in both cases. In a CLONE, the entry is just
> the name of the directory entry.
>
> Yes, ENTRIES can be empty. skel.h should allow an empty list; if it
> doesn't, that's a bug. An empty list is a skel_t whose `is_atom' and
> `children' members are both zero.
If you don't mind, I'll fix "structure" and "skel.h" to reflect that.
Tomorrow, that is.
>> Sorry for being so pedantic, but I'm trying to wrap my head
>> around this, and the questions just popped up. And don't
>> worry, I'll be asking more questions soon, no doubt. :-)
>
>
> No problem! If you can think of a simpler way to track cloning, do
> let me know. Keep in mind that the base revision can do arbitrary
> structure sharing, and in fact, will do so in everyday cases.
Hmm, yes, I was thinking about that. My very first thought was that
storing the entry name in the directory instead of in the node revision
could be less than a good thing, especially as any change in the tables
may have to touch more records than strictly necessary. But I haven't
thought my way throught that yet.
And anyway, it might be a good idea to just implement the spec as it is
now, and worry about design optimisations later. "Prematire optimisation
...", etc. ad nauseam.
> One thing to note about the syntax: I'm imitating the list structure
> notation used in Scheme. The `...' syntax is actually well-defined
> for describing list (or skel) structure --- it means zero or more
> repetitions of the preceding object. So (FOO ...) is a list of zero
> or more FOO's. ((FOO BAR) ...) is a list of zero or more lists, each
> of which contains a FOO, and a BAR. It's less general than writing
> out the recursion in BNF, but it's still very handy.
I guessed as much. I was just trying to make sure I understand what
we're talking about.
Tell you what, I'll fix this along with the "structure" and "skel.h"
changes I proposed, then I'll paste the whole thing as an appendix into
"structure", O.K.? I'm sure it'll help other readers understand what's
going on.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: Some filesystem questions
Posted by Branko Čibej <br...@xbc.nu>.
Jim Blandy wrote:
>>> No, ENTRY isn't the same in both cases. In a CLONE, the entry is just
>>> the name of the directory entry.
>>>
>>> Yes, ENTRIES can be empty. skel.h should allow an empty list; if it
>>> doesn't, that's a bug. An empty list is a skel_t whose `is_atom' and
>>> `children' members are both zero.
>>
>> If you don't mind, I'll fix "structure" and "skel.h" to reflect that.
>> Tomorrow, that is.
>
>
> Okay, but can you explain why you think empty lists are forbidden by
> the statements currently there?
>
Quoting from the initial comment in "skel.h":
A list consists of a byte 40 (ASCII '('), followed by a series of
atoms or lists, followed by a byte 41 (ASCII ')'). There
may be zero or more whitespace characters after the '(' and before
the ')', and between any pair of elements. */
The way I understand that, there must be at least one atom or list
within a list. I propose to insert an "optionally" before the "followed
by a series of atoms or lists". That would make things unambiguous.
Ah .. stupid me, it says there that "A list may contain zero or more
elements". So I'm dumb and can't remember what I read a few lines
before. Forget it then.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: Some filesystem questions
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
> > No, ENTRY isn't the same in both cases. In a CLONE, the entry is just
> > the name of the directory entry.
> >
> > Yes, ENTRIES can be empty. skel.h should allow an empty list; if it
> > doesn't, that's a bug. An empty list is a skel_t whose `is_atom' and
> > `children' members are both zero.
>
> If you don't mind, I'll fix "structure" and "skel.h" to reflect that.
> Tomorrow, that is.
Okay, but can you explain why you think empty lists are forbidden by
the statements currently there?
Re: Some filesystem questions
Posted by Branko Čibej <br...@xbc.nu>.
Jim Blandy wrote:
> Not other kinds of records, but if we wanted to adjust the format of
> the revision skel, we could identify new-format revisions with
> ("revision-2" THING ...). The idea is that this data is going to live
> a long time, so there should be room for version tags on most data.
Ah, O.K. That's reasonable.
>> Surely that can't be right? If the number ranges are correct, then the
>> mapping should be "filesystem revision V -> record number V+1".
>
>
> You're right, the text should be changed as you suggest.
Committed.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: Some filesystem questions
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> Branko �ibej wrote:
>
> > Tell you what, I'll fix this along with the "structure" and "skel.h"
> > changes I proposed, then I'll paste the whole thing as an appendix
> > into "structure", O.K.? I'm sure it'll help other readers understand
> > what's going on.
>
> I just commited a change to the "structure" file, renaming ENTRY to
> ENTRY-NAME in the Clones section, and adding the appendix. Please yell
> if I goofed.
>
> Now I have two more questions, regarding the filesystem revisions table.
>
> 1) Why is the revision skel ("revision" ID PROPLIST), instead of just
> (ID PROPLIST)? Will there be other kinds of records in the "revisions"
> table?
Not other kinds of records, but if we wanted to adjust the format of
the revision skel, we could identify new-format revisions with
("revision-2" THING ...). The idea is that this data is going to live
a long time, so there should be room for version tags on most data.
I agree this is a somewhat weak justification. One can always stick
additional data on the end of the list. It's just a pattern that's
useful elsewhere, and applied here out of habit.
> 2) The table description says:
>
> Since Berkeley DB record numbers start with 1, whereas Subversion
> filesystem revision numbers start at zero, revision V is stored as
> record number V-1 in the `revisions' table.
>
>
> Surely that can't be right? If the number ranges are correct, then the
> mapping should be "filesystem revision V -> record number V+1".
You're right, the text should be changed as you suggest.
Re: Some filesystem questions
Posted by Branko Čibej <br...@xbc.nu>.
Branko �ibej wrote:
> Tell you what, I'll fix this along with the "structure" and "skel.h"
> changes I proposed, then I'll paste the whole thing as an appendix
> into "structure", O.K.? I'm sure it'll help other readers understand
> what's going on.
I just commited a change to the "structure" file, renaming ENTRY to
ENTRY-NAME in the Clones section, and adding the appendix. Please yell
if I goofed.
Now I have two more questions, regarding the filesystem revisions table.
1) Why is the revision skel ("revision" ID PROPLIST), instead of just
(ID PROPLIST)? Will there be other kinds of records in the "revisions"
table?
2) The table description says:
Since Berkeley DB record numbers start with 1, whereas Subversion
filesystem revision numbers start at zero, revision V is stored as
record number V-1 in the `revisions' table.
Surely that can't be right? If the number ranges are correct, then the
mapping should be "filesystem revision V -> record number V+1".
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/