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

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > The point is, essentially, that a "changeset manipulation library"
    > would be best arranged with its data structures following this model -
    > and that what tla currently does is much nastier, as it follows the
    > changeset format instead. And there's no particularly good reason why
    > it should be that way, other than history.

There's always `changeset-report.[ch]' which is closer to what you're
looking for, I think.


    > > 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.


    > > 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.   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.   By extension,
allowing in arbitrary annotation would also make sense.)


    > > I think we should just "solve" the debate about *whether* to change
    > > the changeset and archive and project tree formats by simply deciding
    > > that, yes, we will, but all at once, and not in a hurry.

    > I think it's more or less inevitable - no single desired change is
    > enough alone, but we've got so *many* things that would be nice to
    > have that it's almost certainly worthwhile. On reflection, my guess of
    > "sometime around tla 2.0" seems realistic. That's probably next year.

We have to watch out for the crap factor.   The danger, now that the
project is so thoroughly politicized, is that as a group, the
maintainers just go wandering off into la la land and add all kinds of
utter dead-end crap to changesets (or archives or revlibs ....)


    > Project trees are distinct, though. I can't see any reason to change
    > those at the same time (are there even any things about them worth
    > changing?).

Bunch of little stuff, yes.

-t