state: lose machineDoc.TxnRevno

state: lose machineDoc.TxnRevno

This means that we don't need to racily refresh a Machine
immediately after adding it. Watcher code that used the
revno now explicitly gets it.

https://code.launchpad.net/~rogpeppe/juju-core/466-machine-no-txnrevno-2/+merge/196275

Requires: https://code.launchpad.net/~rogpeppe/juju-core/467-checkers-deepequals/+merge/196247

(do not edit description out of merge proposal)

[rog, 2013-11-22 13:13:24]

Please take a look.

[fwereade, 2013-12-02 09:11:40]

The following is contingent on the fuzzy DeepEquals being a good idea in the
first place... I suspect it's actually just going to encourage bugs, because the
distinction really does matter in entity documents -- maybe not to go, but
certainly to mongo -- and I'm not sure how helpful it is to pretend they're the
same. Assuming you convince me:

Please move all the deep-equality-related code into deepequal.go and out of
bool.go -- and I think it's probably best to avoid exporting DeepEqual itself.
If it needs an independent existence, please put it somewhere like
utils/reflect.

I'm a bit nervous about jc.DeepEquals vs gc.DeepEquals too -- I see the value of
the jc version in certain circumstances, but a one-char difference feels
somewhat developer-hostile. How about DeepAlmostEquals?

https://codereview.appspot.com/30900043/diff/20001/testing/checkers/bool.go
File testing/checkers/bool.go (right):

https://codereview.appspot.com/30900043/diff/20001/testing/checkers/bool.go#n...
testing/checkers/bool.go:91: }
This doesn't look very booley to me.

https://codereview.appspot.com/30900043/diff/20001/testing/checkers/deepequal.go
File testing/checkers/deepequal.go (right):

https://codereview.appspot.com/30900043/diff/20001/testing/checkers/deepequal...
testing/checkers/deepequal.go:155: func DeepEqual(a1, a2 interface{}) bool {
Not sure about the value of exporting this tbh.