status and commit uses different algorithms to find changes

[John Arbash Meinel]

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

Alexander Belchenko wrote:
> Hi John,
> 
> Once not so while ago we talked in IRC and I said that it's to sad that
> commit don't use
> working tree's iter_changes() method to collect changes for commit. As I
> remember you
> said that it's not true and in reality commit uses it.

I wouldn't have said that, as I know commit does *not* use
iter_changes(). It can't, because of issues when there are more than one
parent. We have to compare against both sides, *and* pay attention to
last-modified revisions, while iter_changes() does not.

A while back Ian wrote a patch which turned on a special case when there
was a single parent, and used iter_changes in that circumstance. IIRC
Robert didn't like having the special case in there.

> 
> I can show use case where commit behaves differently than status in the
> same tree:

...

> C:\Temp\stvsci>bzr ci -m1
> Committing to: C:/Temp/stvsci/
> added foo
> Committed revision 1.
> 
> C:\Temp\stvsci>bzr st
> removed:
>   foo/
> unknown:
>   FOO/
> 
> So, commit actually collect changes not via iter_changes, or uses
> iter_changes data incorrectly.
> I think there is already bug report filed about case-insensitive
> filesystems and maybe even not one,
> but IMHO problem not in case-insensitive filesystem. Bug in commit's
> collector code.


commit *isn't* using 'iter_changes'. It is going out and using
"os.lstat()" on all the records it thinks it needs to inspect, which on
a case insensitive system will return a value. 'iter_changes' uses
list_dir() and the does its own filename comparison, which will see the
files/dirs as different objects.

What we *should* do is write something like iter_changes which handles
the extra stuff that commit needs. However, it ends up as a rather large
overhaul of our commit logic. And I think Robert is focusing on
reworking Inventory so that the data recorded can allow us to improve
things higher up the stack, rather than pushing down from above.

I'm not entirely sure where things were left with what Ian and Robert
were discussing with the commit code. I can agree, though, that having a
special case for 1-parent, and then stuff like your commit would work in
a plain commit, but fail for a merge commit, wouldn't really be optimal
either.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjss2EACgkQJdeBCYSNAANqNQCdG+jCHdAfFM9Ip44qIjbf6A80
Ac4AoKVeVeS0BNcQy2QrhkWAzymJeEqs
=pt/o
-----END PGP SIGNATURE-----