[svnbook] r4374 committed - * en/book/ch05-repository-admin.xml...

[Daniel Shahaf]

C. Michael Pilato wrote on Wed, Jan 30, 2013 at 09:46:40 -0500:
> On 01/30/2013 09:22 AM, Daniel Shahaf wrote:
> > svnbook at googlecode.com wrote on Tue, Jan 29, 2013 at 18:50:51 +0000:
> >>          <term>format</term>
> >>          <listitem>
> >> -          <para>A file that contains a single integer that
> >> -            indicates the version number of the repository layout</para>
> >> +          <para>A file that describes the repository's internal
> >> +            organizational scheme</para>
> > Can you mention here that this is not db/format ?
> >
> > It doesn't seem to be already mentioned:
> > % grep '[>/]format<' *
> > ch05-repository-admin.xml:        <term>format</term>
> 
> Yeah, it's not mentioned because the book doesn't describe the internals of
> the db/ directory.  Why do you feel that this "format" vs. "db/format"
> distinction needs to be made?

Because there is repeated user confusion:

    "What does the $REPOS_DIR/db/format file contain?"
    "5"
    "No, not that 'format' file, the other one in the subdir"
    (relying on the fortunate fact that neither FSFS nor BDB ever released a format 5)

I also filed a milestone-2.0 issue to rename *both* format and db/format
(to repos-format and db/fsfs-format, for example), to avoid the chance
for confusion.

> And do you have suggestions for how to call this out without violating
> the intentional opacity of the db/ subdir in the text?
> 

No.

> I suppose that with the introduction of fsfs.conf, the book really needs to
> go ahead and break through that original intended opacity and give
> administrators more of a clue about configuring their repositories.  We have
> an "FSFS Configuration" section, but it's kinda lame.
> 

Agreed: fsfs.conf is user-facing, so it deserves being documented.

> -- C-Mike
> 
> PS:  Hrm... wonder if anyone would benefit from an 'svnadmin info' subcommand:
> 
> $ svnadmin info /path/to/repos
> Path: /path/to/repos
> Format: 5
> FS Type: fsfs
> 

+1, I've had that idea too a few times, never got around to implementing it.

>