Re: Proposed change to skel representation

cmpilato@collab.net writes:
> > If we believe this is worth changing for easier debuggability, it
> > would probably be best to do so before 1.0. We can change it in a
> > phased backward-compatible manner like we've done with date formats.

I think I'm -0 with Mike. Even if space is not the separator between
the count and the data in a counted-length atom, there may still be a
space *in the data*. For example:

   (3 x y blah 7 Hi, mom)

That's three atoms: "x y", "blah", and "Hi, mom".

It's true that our table keys don't ever have spaces, so for much of
the human-eye parsing done during debugging, this issue wouldn't come
up. But I've found that I've gotten used to it pretty quickly.

If we were going to change something, I'd prefer the following simpler
(and also backwards-compatible) change...

There are two confusing things about the current schema:

   - We support both counted-length and implicit-length atoms. So an
     atom can look like two thingies, in the former case, or one
     thingy, in the latter (speaking of human-eye parsing, of course).

   - For the counted-length atoms, the separator between the length
     prefix and the data is a space, but under other circumstances
     space can be a delimiter between two separate atoms. Ick.

What if we start *always* using counted-length, and make the separator
inside counted-length atoms be ":" instead of " "? Thus:

  (svndiff 1 0 2 1a) === becomes ===> (7:svndiff 1:0 2:1a)

and

  (3 x y fish 3 bye) === becomes ===> (3:x y 4:fish 3:bye)

The former example is the sort of thing we'd see a lot during
debugging; the latter is more likely to be part of data in the
`strings' table, not something one often has to dump.

But you know, (7:svndiff 1:0 2:1a) seems less readable to me than
(svndiff 1:0 2:1a), so -0 on that part of my own proposal :-). We
might change the separator, but it's still nice to have two sorts of
atoms.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 29 17:07:26 2002