Re: [Gnu-arch-users] [QUESTION] integrity of changeset.

[Tom Lord]

    > From: Tez Kamihira <address@hidden>

    [re: address@hidden/docs-hackerlab--devo--1.0--patch-1]

    > In changeset:

    >   
A_./{arch}/docs-hackerlab/docs-hackerlab--devo/docs-hackerlab--devo--1.0/address@hidden/patch-log/patch-1

    > But in patch-1 revision:

    >   
?./{arch}/docs-hackerlab/docs-hackerlab--devo/docs-hackerlab--devo--1.0/address@hidden/patch-log/patch-1

    > How can I understand the above difference of inventory name ?

Well, it's a bug.

Fortunately it's not as nasty a bug as it might seem at first.

The bug is that when `commit' adds the new log entry to the changeset
it's making, it always use an 'A_' tag.   In a tree using the `names' 
tagging method, it should really be using a '?' tag.

The resulting changeset applies precisely just fine, and in forward
cases, imprecisely -- e.g., there's no problem `get'ing the resulting
revisions.

If applied with --reverse, it will fail to delete the corresponding
log file.   

Off the top of my head, I don't see other uses of the changeset that
will do the wrong thing (e.g., redundently adding the file during an
imprecise patch, even over a modified copy, should do something
reasonable).

So, the bug only applies to `names' based trees, the practical side
effect is that `replay --reverse' won't do quite the right thing on
those changesets.    The theoretical side effect is that if you're
building some tool, like, say, a browser which wants to parse the
changesets, these will confuse it.

(`replay' without --reverse, `update', and `star-merge' are not
effected by this.   `replay --reverse' is, again, effected only on
`names' trees and only wrt deleting the log entry.)

It's easy enough to fix the bug going forward -- to generate correct
changesets from now on.

It's also easy enough to retroactively fix existing changesets -- if
anyone feels a pressing need to do that.  (I don't, at the moment, for
my `names' trees.)

I think on a tolerant-in-what-you-receive sense, a browser shouldn't
spaz out too badly in the face of the bug.   If your browser happens
to know it's looking at a names-method tree, it could even work around
the bug quite effectively.

I'll put a little work-around in dopatch so that `replay --reverse'
will work correctly with these old changesets when I fix the bug.

-t