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