Martin Pool wrote:
> I'm not so sure about lazily opening, but rather just explicitly
> opening it when we need it, and fixing code that opens it but doesn't
> need it.
I count 124 calls WorkingTree.open* and 127 calls to Branch.open*. You
are proposing to update all 251 calls?
I think this is premature optimization. Has anyone observed a
performance difference? You shouldn't, because your working tree's
repository should always be local or on a fast link.
I think it's a good thing for operations to fail if the repository is
missing. The sooner we inform people about that problem, the easier it
will be to fix. If status only fails when there are pending merges, you
may not know about the problem until it is too late.
>> - most commands do need the repository
>
> Whether it's "most" or not there are certainly many that do not.
Any command that takes a revision spec may use the repository. This
includes "status", Alexander's example. Status will also use the
repository if there are pending merges.
I like the current API. I think it's less friendly to require most
Branch.open* and WorkingTree.open* calls to be followed by
branch.open_repository().
So I think the speed claim is premature optimization. I think that the
desire for operations to succeed when the tree is malformed is
wrongheaded. I think explicitly opening the repository is a less
friendly API than our current one. I think the gains do not justify the
costs.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> I'm not so sure about lazily opening, but rather just explicitly
> opening it when we need it, and fixing code that opens it but doesn't
> need it.
I count 124 calls WorkingTree.open* and 127 calls to Branch.open*. You
are proposing to update all 251 calls?
I think this is premature optimization. Has anyone observed a
performance difference? You shouldn't, because your working tree's
repository should always be local or on a fast link.
I think it's a good thing for operations to fail if the repository is
missing. The sooner we inform people about that problem, the easier it
will be to fix. If status only fails when there are pending merges, you
may not know about the problem until it is too late.
>> - most commands do need the repository
>
> Whether it's "most" or not there are certainly many that do not.
Any command that takes a revision spec may use the repository. This
includes "status", Alexander's example. Status will also use the
repository if there are pending merges.
I like the current API. I think it's less friendly to require most open_repository ().
Branch.open* and WorkingTree.open* calls to be followed by
branch.
So I think the speed claim is premature optimization. I think that the
desire for operations to succeed when the tree is malformed is
wrongheaded. I think explicitly opening the repository is a less
friendly API than our current one. I think the gains do not justify the
costs.
Aaron enigmail. mozdev. org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFGOfZn0F+ nu1YWqI0RAtMnAJ 44UMn+bL27ZGnuE zO1ZDJAqqpcfwCg h9w7 kNt4+mvk=
M9BvzFpHH11ZONB
=5A+I
-----END PGP SIGNATURE-----