[MERGE] Support fetching a restricted set of revisions
John Arbash Meinel
john at arbash-meinel.com
Mon Jul 16 19:43:34 BST 2007
-----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-----
More information about the bazaar
mailing list