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

[Tom Lord]

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

There's a small catch about tracking containing-directory ids: Larch
didn't do it reliably.  Today's mkpatch/dopatch does.  At the same
time, today's is still upwards compatible with larch's and I think
this is good.  It pushes arch towards being robust and failing
gracefully in the face of slightly bogus changesets generated by third
party software.


    > Each of these individual items has changes stored in a changeset in
    > some manner. The data body for regular files is obvious and
    > well-understood. The others are obvious but not so well-recognised;
    > the filename and parent directory should (but actually currently don't
    > in all cases) behave exactly like the body of a symlink - store 'orig'
    > and 'mod', apply with
    > "if current =3D=3D orig, current :=3D mod else conflict".

    > With this as the data structure, all the operations become very simple
    > to specify precisely. 

Welcome to my room.   Don't you like how nicely it's decorated? :-)

    > A moderate number of currently open bugs also
    > get swept away at the same time without complicating the process of
    > changeset application. Good examples are "moving the root of one
    > project into a subdirectory of another", and "adding a file, when its
    > parent directory has since been renamed".

The current special treatment of "." is debatable but not obviously
wrong.  That's one we have to discuss, not presume.


    > All of this information can be constructed from current changesets
    > (almost, there's a bug open about parent directories). 

Ah.  Bummer.  Yeah, larch got it seriously wrong.  It was Real Fun
trying to preserve upward compatability.

tla seems to get it ("almost", apparently) entirely right.   The best
part is that dopatch is pretty graceful about bogus changesets ---
let's not hork that, please.


    > However, this
    > is the "natural" representation, which is what you want to be working
    > on in a program - so we could save some trouble and just store it that
    > way in the first place.

Over the coming months I anticipate we'll be discussing some more
about how map set-structured or vaguely-relational data into
filesystem trees.   


    > Top of my head, here's a completely arbitrary way it *could* be done
    > (not the best, I don't think, I just pulled it out of the air; we
    > really need to do this starting from objectives):

    > For each file $id, the directory files/$id/ in the changeset
    > represents it. This directory contains:

    >  - (a file 'body-patch') or (a file orig-body and a file mod-body) or (a
    >    file orig-target and a file mod-target) or (), depending on the
    >    logical file type.
    >  - (a file 'orig-name') and (a file 'mod-name')
    >  - (a file 'orig-parent') and (a file 'mod-parent')
    >  - (etc)

    > For each file $id, the symlink tree/$full_path/$filename links to
    > files/$id/ - so you have what looks like a partially populated project
    > tree, but made up of symlinks to file-changesets. (This is an index,
    > for things that want a filename->id mapping, craftily arranged so that

Interesting.

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.

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?


    > 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 like changes to changesets that make changesets more navigable .....


-t