Berkeley's db_dump is your friend. Your *best* friend.

[Karl Fogel <kf...@galois.collab.net>]

Filesystem developers will want to be able to type this in their
sleep:

   db_dump -p nodes

where "nodes" is the table you're inspecting (most often it is nodes,
right?).

Of course, make sure you use the right db_dump for the Berkeley DB
your svn linked against.  Some systems have older `db_dump's
installed.

-Karl

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Karl Fogel <kf...@galois.collab.net>]

Jim Blandy <ji...@zwingli.cygnus.com> writes:
> I think you misunderstand.  The actual string stored in the database
> really contains ordinary newline characters.  If you print it in the
> simplest, most obvious way --- like, with `puts' or `fwrite' --- you
> get a nicely indented thingy.  There's no translation necessary.
> Instead, it's db_dump that is "going to the trouble" to print the
> newlines as backslashed hex sequences.

Yes, that's what I understood.  But since I'm using db_dump to view
it, that trouble db_dump goes through still affects me.

> If you were debugging syntax errors in skels, or something similar,
> yes.  But if your problem is at a higher level, the indentation could
> be helpful.  Taken at your word, the logical conclusion would be that
> indentation must never be trusted when debugging, because it's not
> what the parser actually cares about.  But I know you don't actually
> function that way.
> 
> But anyway, I'll take out the indentation.

Oh, there are certainly times when the indentation would be helpful!
But there are also times when it's just in the way...  (Someday if we
really need a "svn_fs_pretty_print_skel" function for debugging, it
wouldn't be hard to write, anyway).

-K

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Jim Blandy <ji...@zwingli.cygnus.com>]

Karl Fogel <kf...@galois.ch.collab.net> writes:
> Jim Blandy <ji...@zwingli.cygnus.com> writes:
> > If you actually print that out without the backslashing (i.e. \0a is a
> > newline), you'll get an indented view of the skel.  However, I'm
> > thinking the indentation probably isn't worth it.  Wouldn't you rather
> > see
> > 
> >   (fulltext ((dir ()) ()))
> > 
> > ?
> 
> Yeah, I think that might be easier to debug, since I doubt anyone is
> going to take the trouble to translate the newlines correctly
> anyway. :-)

I think you misunderstand.  The actual string stored in the database
really contains ordinary newline characters.  If you print it in the
simplest, most obvious way --- like, with `puts' or `fwrite' --- you
get a nicely indented thingy.  There's no translation necessary.
Instead, it's db_dump that is "going to the trouble" to print the
newlines as backslashed hex sequences.

> And personally, I usually verify s-expression boundaries by using sexp
> motion commands in my editor; the indentation would be a further clue,
> but not really necessary -- if I were debugging something, I'd
> probably be looking *very* hard at the exact sexps, independent of
> indentation.

If you were debugging syntax errors in skels, or something similar,
yes.  But if your problem is at a higher level, the indentation could
be helpful.  Taken at your word, the logical conclusion would be that
indentation must never be trusted when debugging, because it's not
what the parser actually cares about.  But I know you don't actually
function that way.

But anyway, I'll take out the indentation.

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Karl Fogel <kf...@galois.collab.net>]

Jim Blandy <ji...@zwingli.cygnus.com> writes:
> If you actually print that out without the backslashing (i.e. \0a is a
> newline), you'll get an indented view of the skel.  However, I'm
> thinking the indentation probably isn't worth it.  Wouldn't you rather
> see
> 
>   (fulltext ((dir ()) ()))
> 
> ?

Yeah, I think that might be easier to debug, since I doubt anyone is
going to take the trouble to translate the newlines correctly
anyway. :-)

And personally, I usually verify s-expression boundaries by using sexp
motion commands in my editor; the indentation would be a further clue,
but not really necessary -- if I were debugging something, I'd
probably be looking *very* hard at the exact sexps, independent of
indentation.

-K



> Ben Collins-Sussman <su...@newton.ch.collab.net> writes:
> > Wow, this is amazing.  Here's a printout of the repos right after
> > running fs-test #6, the one which creates an empty file:
> > 
> > --------------------------
> > VERSION=2
> > format=print
> > type=btree
> > HEADER=END
> >  0.0
> >  (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a    )\0a    (\0a    )\0a  )\0a)
> >  0.1
> >  (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a      (\0a        mutable \0a        0\0a\0a      )\0a    )\0a    (\0a      (\0a        beer.txt \0a        3\0a1.1\0a      )\0a    )\0a  )\0a)
> >  1.1
> >  (\0a  fulltext \0a  (\0a    (\0a      file \0a      (\0a      )\0a      (\0a        mutable \0a        3\0a0.1\0a      )\0a    )\0a    0\0a\0a  )\0a)
> > DATA=END
> > ---------------------------
> > 
> > Notice node-rev 0.0 is a dir with no mutable flag, and no dirents.
> > This is the "root" node made when the fs is created.
> > 
> > Notice that 0.1 is the root of the first transaction: it's a clone of
> > the root node.  How can we tell?
> > 
> >   * You can tell they're both revisions of node 0, because they're
> >     both named "0.*".
> > 
> >   * The only difference between 0.0 and 0.1 is that the the latter has
> >     the "mutable" flag.
> > 
> > And finally, notice our new empty file -- node 1.  It's of type
> > "file", has the mutable flag (which points to parent 0.1), and has no
> > content.
> > 
> > Whee!
> > 
> >

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Jim Blandy <ji...@zwingli.cygnus.com>]

If you actually print that out without the backslashing (i.e. \0a is a
newline), you'll get an indented view of the skel.  However, I'm
thinking the indentation probably isn't worth it.  Wouldn't you rather
see

  (fulltext ((dir ()) ()))

?

Ben Collins-Sussman <su...@newton.ch.collab.net> writes:
> Wow, this is amazing.  Here's a printout of the repos right after
> running fs-test #6, the one which creates an empty file:
> 
> --------------------------
> VERSION=2
> format=print
> type=btree
> HEADER=END
>  0.0
>  (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a    )\0a    (\0a    )\0a  )\0a)
>  0.1
>  (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a      (\0a        mutable \0a        0\0a\0a      )\0a    )\0a    (\0a      (\0a        beer.txt \0a        3\0a1.1\0a      )\0a    )\0a  )\0a)
>  1.1
>  (\0a  fulltext \0a  (\0a    (\0a      file \0a      (\0a      )\0a      (\0a        mutable \0a        3\0a0.1\0a      )\0a    )\0a    0\0a\0a  )\0a)
> DATA=END
> ---------------------------
> 
> Notice node-rev 0.0 is a dir with no mutable flag, and no dirents.
> This is the "root" node made when the fs is created.
> 
> Notice that 0.1 is the root of the first transaction: it's a clone of
> the root node.  How can we tell?
> 
>   * You can tell they're both revisions of node 0, because they're
>     both named "0.*".
> 
>   * The only difference between 0.0 and 0.1 is that the the latter has
>     the "mutable" flag.
> 
> And finally, notice our new empty file -- node 1.  It's of type
> "file", has the mutable flag (which points to parent 0.1), and has no
> content.
> 
> Whee!
> 
>

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Karl Fogel <kf...@galois.ch.collab.net> writes:

> Filesystem developers will want to be able to type this in their
> sleep:
> 
>    db_dump -p nodes
> 

Wow, this is amazing.  Here's a printout of the repos right after
running fs-test #6, the one which creates an empty file:

--------------------------
VERSION=2
format=print
type=btree
HEADER=END
 0.0
 (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a    )\0a    (\0a    )\0a  )\0a)
 0.1
 (\0a  fulltext \0a  (\0a    (\0a      dir \0a      (\0a      )\0a      (\0a        mutable \0a        0\0a\0a      )\0a    )\0a    (\0a      (\0a        beer.txt \0a        3\0a1.1\0a      )\0a    )\0a  )\0a)
 1.1
 (\0a  fulltext \0a  (\0a    (\0a      file \0a      (\0a      )\0a      (\0a        mutable \0a        3\0a0.1\0a      )\0a    )\0a    0\0a\0a  )\0a)
DATA=END
---------------------------

Notice node-rev 0.0 is a dir with no mutable flag, and no dirents.
This is the "root" node made when the fs is created.

Notice that 0.1 is the root of the first transaction: it's a clone of
the root node.  How can we tell?

  * You can tell they're both revisions of node 0, because they're
    both named "0.*".

  * The only difference between 0.0 and 0.1 is that the the latter has
    the "mutable" flag.

And finally, notice our new empty file -- node 1.  It's of type
"file", has the mutable flag (which points to parent 0.1), and has no
content.

Whee!

Re: Berkeley's db_dump is your friend. Your *best* friend.

[Karl Fogel <kf...@galois.collab.net>]

Karl Fogel <kf...@galois.collab.net> writes:
> Filesystem developers will want to be able to type this in their
> sleep:
> 
>    db_dump -p nodes
> 
> where "nodes" is the table you're inspecting (most often it is nodes,
> right?).
> 
> Of course, make sure you use the right db_dump for the Berkeley DB
> your svn linked against.  Some systems have older `db_dump's
> installed.

Oops -- but, should point out that there may be information in your
db's "log.00000..." file, which db_printlog can tell you about.

-K