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

[Andrew Suffield]

On Tue, Aug 17, 2004 at 08:13:33PM -0700, Tom Lord wrote:
> 
>     > From: Andrew Suffield <address@hidden>
> 
>     > Avoiding spending too long on this, briefly the metaphor is:
> 
>     > The operational set is a group of logical files. Every logical file
>     > has a permenant and immutable identifier (the inventory id). Every
>     > logical file also has:
> 
> [a per-revision]
> 
>     >  - a type (file/symlink/directory)
>     >  - a data body (for files and symlinks, not for directories)
>     >  - a filename
>     >  - a logical file identifier which represents the parent directory
>     >    (NULL/undef/whatever for the root directory)
>     >  - some permission bits
>     >  - (etc)
> 
> That's pretty much my mental model.

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.

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

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

>     > None of this is enough to make it worthwhile to change the changeset
>     > format - you can do it all in-core with the current format (or
>     > something very close) and just arrange your internal data structures
>     > that way. But if we're changing it *anyway*, then we have the
>     > opportunity to simplify arch implementations a fair bit and also make
>     > changesets easier to understand.
> 
> 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.

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

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

signature.asc
Description: Digital signature