[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [QUESTION] integrity of changeset.
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [QUESTION] integrity of changeset. |
Date: |
Sat, 27 Sep 2003 10:44:08 -0700 (PDT) |
> 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