bb very slow?

[John Arbash Meinel]

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

Aaron Bentley wrote:
| John Arbash Meinel wrote:
|> Aaron Bentley wrote:
|> | In order to accomodate PQM's revision-ids, I've had to switch to a
|> | slow-but-safe way of determining whether a merge occurred.  So whenever
|> | there's a new HEAD in bzr (or a monitored project with a similar-size
|> | ancestry), we may see this kind of behavior.
|
|> How are PQM's revision ids different than others?
|
| They have percent signs in them.
|
|> Could you do something
|> like:
|
|> # cache the ancestry of the current tip
|
|> # when tip changes use
|> g = b.repository.get_graph()
|> new = g.find_unique_ancestors(new_tip, [old_tip])
|> ancestry.add(new)
|
| Interesting.  I'm not used to thinking about the long-livedness of this
| process.
|
|> for patch in unmerged_patches:
|> ~  if patch.revision_id in ancestry:
|> ~    # This has been merged
|
| So I'm currently constructing an SQL query for all requests that are
| unmerged but whose head revision is in the ancestry.  That also has
| performance advantages, since only a requests will survive that filtering.
|
| Your approach will probably deliver reasonable performance, but it's
| frustrating to have to change approaches just because SQLAlchemy can't
| efficiently encode a test for whether a value is a member of a set.
|
|> Alternatively the final check could be done on just "new" and you
|> wouldn't need to cache the whole ancestry.
|
| Call me paranoid, but I think it's safer to check against the whole
| ancestry.
|
| Aaron

Paranoid

It *is* a bit safer. I don't think it is any more correct. If it *is*
then we have a bug somewhere.

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

iEYEARECAAYFAkh/besACgkQJdeBCYSNAANdMQCfSlvQnPni7VmxP0jUVqZVQm0k
iFQAoMKXuZUr6Zr+CPGMup5Ht4YrUmJY
=wtti
-----END PGP SIGNATURE-----