Comment 1 for bug 430311

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

John A Meinel wrote:
> Public bug reported:
>
...

> The ideal would be to have a single master connection opened and
> maintained, and then sub-connections opened whenever we actually need to
> do something. That way, we don't have to worry about deadlocks, or
> having 2 threads trying to both do something over the socket at the same
> time.
>
> In the worst case, maintaining 1 connection per branch would be ok.
> Having to re-connect everytime you "Refresh" is just stupid slow.
>
> ** Affects: bzr-explorer
> Importance: Undecided
> Status: New
>

Note that a major detractor from this is that we spawn a new subprocess
for most interesting operations. (qlog, qannotate, qcommit, etc are all
separate processes.)
Not only that, but those commands then sometimes spawn *another* subprocess.

So consider the idea of:

 1) I open bzr-explorer and and point it at my working tree
 2) It opens the branch and connects to determine whether or not there
    are local changes.
 3) I then follow the 'Commit the changes' link which spawns qcommit
    under the covers.
 4) This then opens the working tree again to get the information it
    needs about what would need to be committed. (Never mind the fact
    that we already ran status in bzr-explorer...) This yet again opens
    a connection to the remote branch.
 5) We decide everything looks good, type our commit message and press
    ok. This spawns 'bzr commit' under the covers.
 6) Which yet again opens the working tree and branch, though this time
    it takes out a write lock.
 7) The commit finishes, returning control to bzr-explorer
 8) Which then should refresh its working tree state, requiring yet
    another connection to the remote repository, and another password
    entry.

Which means that to start from bzr-explorer through the point of
actually committing something takes 4 prompts even if all the different
steps are not accidentally connecting multiple times.

Perhaps we can keep a connection open in bzr-explorer, but we can't
leave the working tree locked. Because when you spawn a subprocess it
eventually gets to a subprocess that needs to write-lock the working
tree so it can be updated. And that would block versus the read-lock
taken in earlier levels.... ugh

This *really* wants me to re-evaluate the idea of lightweight checkouts
and bzr-explorer. As the stack is pretty much designed to work in the
worst way possible. Even if you have an ssh-agent running, it still
requires 4 ssh handshakes. (In my testing this can be easily 1s+ each
even on the local network.)

Note that this also is triggered for pretty much all the other actions
you'd want to do. "bzr-explorer 'Add'" re-opens the object at least 4
times. (one for status, one for qadd dialog, one for
qadd-actually-do-the-action, one for status when you get back to
bzr-explorer.)

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

iEYEARECAAYFAkqwMUoACgkQJdeBCYSNAAMFPgCgv+do5DL5dVEp4G6i129oWTmN
x5wAn3pixAjVW+fVP4GEnoBDRzqiAb8p
=GSJm
-----END PGP SIGNATURE-----