See the change I committed --- the empty string is the correct value.
The grammar was wrong; the explanation of the `mutable' flag towards
the top of the file specified that PARENT-ID is the empty string for
the root directory.
Certainly one could do it either way, but I prefer it this way. I
think it's more graceful for the `mutable' flag to have a consistent
structure for all nodes. If the PARENT-ID field has a quiescent
value, there's no need to propagate that fact up to the structure
containing it. It also makes it somewhat easier to add more possibly
optional values to the end of the flag.
Karl Fogel <kfogel@galois.ch.collab.net> writes:
> jimb@tigris.org writes:
> > Log:
> > Tweak Karl's tweak of the syntax of the "mutable" flag.
>
> Oh -- am I misunderstanding the BNF syntax? I had thought that true
> emptiness preceding a bar was the way to express actual absence, as
> opposed to "", which would mean an atom representing the empty string.
> It's the difference between these two:
>
> ("mutable")
> ("mutable" "")
>
> where the former is a valid flag, and the latter is... well, at least
> highly unlikely. :-) (See the code in nodes-table.c:is_valid_flag().)
>
> It would have to precede the bar, so it's clear it's not a typo, of
> course. I deduced that syntax from this entry a bit later in
> `structure':
>
> list.body.opt ::= | list.body ;
>
> ?,
> -K
>
> > Revision Changes Path
> > 1.35 +1 -1 subversion/subversion/libsvn_fs/structure
> >
> > Index: structure
> > ===================================================================
> > RCS file: /cvs/subversion/subversion/libsvn_fs/structure,v
> > retrieving revision 1.34
> > retrieving revision 1.35
> > diff -u -r1.34 -r1.35
> > --- structure 2001/02/28 00:52:17 1.34
> > +++ structure 2001/02/28 22:07:10 1.35
> > @@ -634,7 +634,7 @@
> > HEADER ::= (KIND PROPLIST FLAG ...) ;
> > KIND ::= "file" | "dir" | "copy" ;
> > FLAG ::= ("mutable" PARENT-ID) ;
> > - PARENT-ID ::= | node.revision-id ;
> > + PARENT-ID ::= "" | node.revision-id ;
> > SOURCE-REVISION ::= number ;
> >
> >
> >
> >
> >
>
Received on Sat Oct 21 14:36:23 2006