dirstate internals question
Martin Pool
mbp at sourcefrog.net
Tue Aug 12 05:48:11 BST 2008
On Tue, Aug 12, 2008 at 1:10 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> I'm confused by this code in dirstate's update_basis_apply_deletes
>
> if real_delete:
> if entry[1][0][0] != 'a':
> self._changes_aborted = True
> raise errors.InconsistentDelta(old_path, file_id,
> 'This was marked as a real delete, but the
> WT state'
> ' claims that it still exists and is
> versioned.')
> del self._dirblocks[block_index][1][entry_index]
And this is in the context of https://bugs.launchpad.net/bzr/+bug/256409
As the docstring says, real_delete is set when this update to the
dirstate indicates the entry is being removed rather than just moved.
This code runs on the old name for this row, and the assertion is
checking that the current tree minikind is a = absent.
And this code is obviously mirrored from the next block down, handling
the case of removal of entries *not* caused by deletes, where 'a' is
not allowed. It may be that I inserted that assertion when trying to
refactor this code and it's not actually semantically needed.
I wonder why we have that requirement: if we're deleting it, why not
just delete it? Is it perhaps assuming that we only commit the
removal of a file that has been removed from the wt? That would be
consistent with the docstring of update_basis_by_delta, which says
that the delta can only have the effect of making the basis consistent
with the wt.
If so, how do the tests for rm --keep pass? They can pass because, rm
has previously taken that file out of the working inventory. It's
still on disk but it's ignored (or unknown). (But it might be useful
to test this area more to reproduce the failure?)
On the other hand if we're marking the file absent, then separately
going through to remove the row, that seems like an opportunity for
improvement.
In almost every branch of _update_basis_apply_deletes, unless an error
is raised, we end up deleting the entire entry from the dirblock,
meaning that we no longer have any data about that filename in the
working tree, basis tree, or any of the merged-in trees.
--
Martin <http://launchpad.net/~mbp/>
More information about the bazaar
mailing list