Restoring history of a "bzr remove"d file
Matthew D. Fuller
fullermd at over-yonder.net
Sun Feb 6 14:59:48 UTC 2011
On Sun, Feb 06, 2011 at 09:41:17AM -0500 I heard the voice of
Eli Zaretskii, and lo! it spake thus:
>
> It is less clear what exactly happens with the file's history
> records.
Mostly because the concept of "file's history" itself is pretty
unclear...
> So the history information is largely unaltered, but somehow the
> history of this one file _is_, because I can again "bzr annotate"
> it. (Previously, I thought the history was not altered at all, but
> now I realize I was wrong).
No, the history isn't touched at all. Files don't have history;
history has files. By doing the revert, you're setting something up
to _add on_ to the history (when you commit, if you don't toss it
aside first), but you're not touching any of the existing history.
Alternately phrased: revert doesn't touch the repository or branch at
all, only the working tree.
Any time you're looking through history, you never look at file
_names_, just id's. If you `bzr log src/foo.c`, it doesn't look
through the history for foo.c. It looks in the tree to find out what
file-id that 'src/foo.c' is, then looks through the history for that
file-id. The name, now or in the past, is just a transient property
of the file-id, much like its contents.
With a little fiddling at the API level, you could add a
"--set-file-id-to=" arg to bzr add, and then you could `bzr add
--set-file-id-to=original_fileid_of_old/file new/file` and get the
same result as our incantation with revert/mv. It doesn't [to bzr]
matter how that file-id came to be set, just that it's the same as
whatever other historical file-id you want it to be conceptually tied
to.
The annotate thing is a pure UI bug (quirk, wart, whatever). If there
were an annotate-by-file-id you wouldn't need the file sitting around
in your current tree as an indirection for the UI to get at the
file-id and then annotate some historical state of it. That's all
annotate is doing with the path you pass it; using it in the current
tree to look up the file-id, which it then rifles through the history
looking for.
Or if annotate were fixed to use that path as a key into the
historical tree as of the rev you passed, rather than just in the
current one (which revert does; else it couldn't do this at all, so
you're sorta using revert's un-bugginess to give you an indirection to
hide annotate's bugginess).
--
Matthew Fuller (MF4839) | fullermd at over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
More information about the bazaar
mailing list