[MERGE] Support fetching a restricted set of revisions

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Jelmer Vernooij wrote:
>> The attached bundle adds a parameter to InterRepository.fetch() to
>> retrieve a limited set of revisions from the source repository and adds
>> an implementation for retrieving a limited set to KnitRepository1. This
>> is a step towards shallow branches.
> 
> Jelmer,
> 
> Exciting to see some progress on this feature!
> 
> I appreciate this isn't exposed at the UI yet and the direction you're
> going has precedence with the --depth option of git clone, but are we
> sure we want to control depth via a numeric limit?
> 
> Thinking out loud, is specifying depth by giving a revision spec a
> better way? We can easily give a depth of N that way (-N) but it opens
> the possibility of specifying the "origin" in more logical ways,
> particularly once people start using tags more heavily. For example,
> "give me depth back to the version tagged (say) 0.17rc1". It just seems
> to me that many people don't want to think about how far they wish to go
> back in terms of a count. Well unless that number is 1 and only 1. :-) A
> 'logical point' in recent project history seems more useful IMO.
> 
> I'm asking this because http://bazaar-vcs.org/HistoryHorizon doesn't
> seem to make a firm UI decision. And I think the UI will impact the API
> down at this level.
> 
> Ian C.

Just to add (hopefully) some clarification.

bzr branch -r X..Y

would allow you to specify any revision spec. Which includes 'tag:0.17rc1' and
'branch:http://bazaar-vcs.org/bzr/bzr.0.17' and
'revid:john at arbash-meinel.com-foo-bar'

I don't know how he was translating that internally. For example:

bzr branch -r -9..-1

Could be interpreted as:
a) Copy the set of all revisions in the ancestry of '-1' which is not present
in the ancestry of '-9'

b) Copy the last 9 mainline revisions (-9, -8, -7, -6, ..., -1). But no merges


I prefer (a) though it does weird things for:
bzr branch -r -1..-2

Which is a NULL set.

Also, there are some questions about the edge cases. Does 'bzr branch -r-5..-1'
copy revision -5, or only [-4,... -1]

Overall I think this is a genuine step in the right direction. I'm mostly
looking forward to something like:

bzr checkout --shallow

(which I would consider making the default) and would give you a branch with
only enough information to recreate the current tip, but would also give you
enough to let you do local-only commits, etc.

(Other side points, should restricted revisions give you a complete ancestry
graph? It would mean that you could still select a merge base even when you
don't have full ancestry, but it means that some portion of bzr branch would
always be O(N) even if the constant was very small).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGm7xWJdeBCYSNAAMRAvL1AJ9ebtxIBcP2/5/lDUTVNmIKpsXp1QCgihNr
fBAPpHvv93xSx4/xtXhFxHs=
=yeqR
-----END PGP SIGNATURE-----