[RFC] dirstate and deletes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Robert's comment is how to handle either a plain 'rm directory/name' or
> a 'bzr rm directory/name'.

These are opposite situations, though.  In one case, the file is
'missing, but versioned', and in the other, it is 'present, but
unversioned'.

> The issue is you still need a place to store the [parent info] even
> though the file has been removed. Because when you go to commit, you
> want to find that it isn't there, but it used to be.

So this is the 'rm foo' case.  Dirstate is intended to be an accurate
representation of the filesystem, so that I can query it about whether a
path exists or not?

> I think leaving the path alone, and just marking that the file has been
> unversioned is a good step. We still need to track it, because commands
> are going to want to know what the state of that file is.

That sounds backwards to me.  The file hasn't been unversioned, it's
missing.  If policy is that missing files should be unversioned at
commit time, then it *becomes* unversioned, sure.  But mainly by being
skipped in _populate_new_inventory, I'd expect.

It seems like dirstate is functioning as both the live inventory and the
basis inventory, no?  So I guess the representation of unversioned files
makes sense.

> I'm okay with that... I wonder, though, if it would be better to allow
> for multiple entries next to each other.
> 
> But dirstate is really designed to be optimized for the: "I have this
> file/dir/symlink at this specific path, what is its state". Which means
> that deleted items don't really do much for that part of the system.

It sounds like this is getting close to the situation that caused me to
come up with transform-ids in TT.  i.e., some paths exist only in the
old, some only in the new, so you can't use paths as an identifier.  But
you can't use file-ids as identifiers, because they're not all versioned.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFBsXo0F+nu1YWqI0RApL1AJ9xpFkR/s5XV8ZduKLIGQlao9idGQCfdN5D
o/UoB315AGSnZEqjo8D/m1w=
=bW8t
-----END PGP SIGNATURE-----