[MERGE/RFC] Shortcut 'iter_references' when we can't have references

[John Arbash Meinel]

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

In playing around with merging, I found that the "WT.iter_references()"
call was showing up somewhat heavily in the time for doing a merge.
Basically, it takes a while because it has to iterate the entire tree,
and possibly for every directory check to see if it is actually a bzr
dir now.

Basically, this is almost as expensive as a full "iter_changes" call,
because it is doing a stat call for each file and directory, and if the
repository supports references, it will then probably try a
"BzrDir.open()" check.

Anyway, we don't actually need to be doing any of this checking on trees
that don't support references, which is what this patch does:

=== modified file 'bzrlib/workingtree_4.py'
- --- bzrlib/workingtree_4.py     2008-06-06 16:40:46 +0000
+++ bzrlib/workingtree_4.py     2008-06-18 15:46:49 +0000
@@ -528,6 +528,10 @@
~         return iter(result)

~     def iter_references(self):
+        if not self._repo_supports_tree_reference:
+            # We can't have references in this type of tree, so the
check here
+            # is easy
+            return
~         for key, tree_details in self.current_dirstate()._iter_entries():
~             if tree_details[0][0] in ('a', 'r'): # absent, relocated
~                 # not relevant to the working tree


Thoughts? It seems a shame to penalize (heavily) our normal code because
we might be supporting references in some formats (that aren't even
considered production worthy yet.) Then again, if we want to make it
production, it might be bad to remove the checking.

I guess part of the problem is that we have chosen to auto-detect when a
file/directory/etc changes kind. So we have to stat everything to see if
it really is a subtree now.

Going further, though, it seems like this could be handled when you
start doing "iter_changes" rather than having you check ahead of time
for sub-trees, and then check again when looking for changes.

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

iEYEARECAAYFAkhZL4YACgkQJdeBCYSNAAPSZgCaAv5l9La4gurOF+3rcuoiHckr
AE0An26tjnv1lfnBlrenUs3y0zLPv3wF
=Ni9Q
-----END PGP SIGNATURE-----