[MERGE] Add helper class versionedfile.VersionedFilesDecorator for use with RemoteRepository in future.
Robert Collins
robert.collins at canonical.com
Wed Feb 25 04:49:32 GMT 2009
On Tue, 2009-02-24 at 09:08 -0600, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> > As NEWS says, a helpful generic VersionedFilesDecorator; Andrew and I
> > intend to use this to avoid calls to 'start_commit_group' on
> > RemoteRepository having to call _ensure_real until actual operations are
> > undertaken.
> >
> > -Rob
> >
> >
>
> So IIRC, the idea is that you'll create one of this and *not* have
> populated the _backing_vf yet. And then once a call is made, to
> "repository.texts" (for example) it will call _ensure_real and then
> populate _backing_vf and respond.
Yup, precisely. Also we want to be able to trap add* and insert* methods
and use them to call repo._real_repository.start_write_group() if
needed, rather than always making a real repo when a write group is
started. This was for fetch, and we solved it another way so it can
actually wait; but we will want one of these soon.
> I'm a bit curious why you pass all the parameters to _hook_call, rather
> than just alerting it that it is being called?
So that RecordingVersionedFileDecorator, used in tests, was able to
subclass this rather than being totally separate.
> Also, why not use the __getattr__ pattern rather than having to proxy
> each function?
I find __getattr__ less clear; perhaps personal preference.
> If you are doing it this way, is there a way to hook it into the generic
> tests, so that we are sure if we add a new VF api, that it also gets
> implemented here?
It is hooked in - the interface tests run against one of these with the
hooking call set to just populate the _backing_vf.
> I'm a little concerned about the overhead of calling _hook_call for
> every action, though the only one we do a lot is get_parent_map. And
> then it should be hundreds and not thousands (though on Emacs, it could
> potentially be 80k or so). Probably it is ok.
Yup, be bad in inner loops - but an inner loop on a RemoteRepository
object is an inner loop with network latency in it - something that is
far worse.
> +class RecordingVersionedFilesDecorator(VersionedFilesDecorator):
> """A minimal versioned files that records calls made on it.
> ...
>
> Instead of passing a function to VFD.__init__ you create an explicit
> 'def _hook_call' function. I think it would be better as:
>
> def _rvf_hook_call(self):
> ...
>
> def __init__(self):
> VFD.__init__(self, hook_call=self._rvf_hook_call)
>
> Or some permutation on that.
>
> I realize what you do *works*, but only as long as you don't call
> super().__init__, which doesn't seem like a good policy to require. At a
> minimum it needs to be documented in __init__. I would prefer if you
> passed the hook_call parameter.
I don't understand this; certainly in bzr we don't use super() anymore
anyhow, but even if we did, what I did works, doesn't it?
-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090225/7355ee43/attachment.pgp
More information about the bazaar
mailing list