[MERGE] Add __eq__ and __ne__ methods to Repository objects

[Robert Collins]

On Mon, 2007-08-06 at 01:32 -0400, Martin Pool wrote:
> Martin Pool has voted tweak.
> Status is now: Conditionally approved
> Comment:
> I think this is ok.  == and != shouldn't be expensive (do network io) or 
> have side effects, but it looks like these don't.
> 
> +    * ``Repository`` objects can now be compared with ``==`` and ``!=`` 
> to
> +      determine if they are the same repository.  (Andrew Bennetts)
> 
> That doesn't seem quite accurate: if you reach the same repository over 
> different urls they'll be seen as different, won't they?  That's 
> probably reasonable as doing otherwise would be too expensive, but it 
> seems like the docstring or something should be clear about just what 
> comparison does and doesn't do.

Martin and I were talking yesterday on the phone, and we happened to
touch on this. I think we both have some deeper concerns about using
__eq__ to indicate equality when Repositories do not act like
'ValueObjects' - they are qualitatively different from e.g. sets, ints,
lists of ints, strings.

Specifically two repository instances in memory may have different state
- different cache contexts, one might be in a write lock and one in a
read lock.

So on reflection __eq__ really seems inappropriate here. What fetch
wants is 'are these two repositories handles to the same physical
resource'. What __eq__ represents is 'do these two objects have the same
value', and these questions are the same.

So I'd like to get this patch backed out, and ask that it be either
discussed further, or not done using __eq__. Given we freeze tomorrow,
backing out *now* seems like a precaution to me.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070807/d01264b4/attachment-0001.pgp