Re: [Gnu-arch-users] the state of the union

[Andrew Suffield]

On Wed, Aug 18, 2004 at 10:23:40AM -0700, Tom Lord wrote:
>     > > That strikes me as a "noop" (no new structure) rearrangement of what's
>     > > already there.   It's an entertaining rearrangement since it makes the
>     > > layout of a changeset tree a little more intuitive and navigable for
>     > > humans.... but it doesn't really change anything other than that.
> 
>     > Well, it does have some different performance characteristics -
>     > partial changeset application is more efficient this way, as you can
>     > fetch precisely the components you need. But that's coincidental (and
>     > assumes it's not been stuffed in a tarball). The important point is
>     > that it simplifies code that follows the above model, since it maps
>     > more or less directly to the desired in-core data structure.
> 
> Changesets are tiny.   You can compute a gazillion different views of
> them before you notice a performance hit.

I'm not betting on them remaining that way. There's no particular
reason why they *should* be tiny in general - summary deltas in
particular will tend to grow in step with the interval of time they
summarise. A changeset from linux 2.4.0 to 2.6.0 is going to be
*huge*, and it's reasonable to say that we should be able to partially
apply it.

That's a completely different discussion, though. I've got a small
sackful of performance issues with changesets that can (and should) be
reasonably easily fixed.

>     > > In all seriousness: on the same principles, perhaps the changeset
>     > > format should expand so that you can also drop in .html files of
>     > > "annotation" about the various changes enclosed?
> 
>     > (I'm ignoring this for now because I don't have the faintest idea, and
>     > don't have time to think it through).
> 
> (I was and slightly still am confused about whether you are talking
> about an API for changesets or the changeset disk format.

Somewhere between the two. There shouldn't be a huge difference. I'm
thinking in general principles, rather than any particularly firm
plans.

> If the
> disk format, and if you want to make an isomorphic change, there being
> precious little performance incentive for such changes, presumably the
> reason is to make the changesets more human-navigable.

"Yes", but I'm primarily thinking about "humans that are writing
programs to manipulate changesets". It just happens to be better for
the others at the same time.

I expect we *can* arrange things so that's they're more easily
navigated in raw form, though.

> By extension,
> allowing in arbitrary annotation would also make sense.)

Allowing arbitrary *anything* would make sense really (one tool should
be able to inject its own private metadata into a changeset, and have
it come out again at the other end), but that's not directly
relevant. It's a relatively minor detail for when we're ready to
actually design the pesky thing.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature