[MERGE] Add optional 'fetch_spec' to argument to Repository.fetch

[Jelmer Vernooij]

On Sun, 2009-03-08 at 15:52 +0100, Jelmer Vernooij wrote:
> On Sun, 2009-03-08 at 17:54 +1100, Andrew Bennetts wrote:
> > Jelmer Vernooij wrote:
> > [...]
> > > It would be nice if the fetch_spec parameter could be documented in
> > > Fetch(). In particular, is it allowed to ignore this parameter ? Will
> > > there be no revision id specified if this parameter is specified?
> > 
> > Yes, Robert pointed out the lack of documentation in his review too, so I
> > extended the docstring as part of the tweaks to land the branch.  It now
> > says:
> > [...]
> > I hope that answers your questions.  If it doesn't let me know and I'll try
> > to improve the docstring some more.
> Thanks, that helps. 
> 
> > Btw, in a couple of places (e.g.  InterPackRepo) that I didn't want to
> > update for fetch_spec I put in some code like:
> > 
> >         if fetch_spec is not None:
> >             if len(list(fetch_spec.heads)) != 1:
> >                 raise AssertionError(
> >                     "InterPackRepo.fetch doesn't support "
> >                     "fetching multiple heads yet.")
> >             revision_id = fetch_spec.heads[0]
> >             fetch_spec = None
> > 
> > Which is just a simple backwards compatibility thing; currently the only
> > fetch_spec used in bzr.dev is a PendingAncestryResult with a single head
> > (and then only when sprouting or cloning into a newly created and
> > non-stacked repo), so it's easy to treat that like a single revision_id as
> > before.  Perhaps your plugins will want to do the same thing?
> Thanks, I'll give that a try. Can I expect there to always be a "heads" variable in a fetch_spec ? 
In particular, it looks like SearchResult doesn't have a "heads" member.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org