History horizons: how hard can they be ?
robertc at robertcollins.net
Mon Nov 16 00:18:23 GMT 2009
On Sun, 2009-11-15 at 18:54 +0100, Jelmer Vernooij wrote:
> Imports from foreign branches are currently quite slow. This has got to
> do with the fact that we actually have to process all of the data and
> can't just copy verbatim as we can when cloning between two repositories
> with the same format. In Subversion's case there is also the fact that
> fetching all data in a repository is relatively slow.
> Stacking seems like a good solution here, but unfortunately we don't
> support inter-format stacking yet and it won't be trivial to implement
> inter-format stacking.
> Another option is supporting history horizons - just letting everything
> except for the last X revisions on the mainline be a ghost. This would
> work well at least for bzr-svn.
> As far as I can tell the only things required to support history
> horizons properly are:
> * have a --horizon X option to 'bzr branch' that limits the revisions
> to fetch
> * have a branch.conf option that limits the revisions to fetch
> * support ghosts on the mainline well (there are some open bugs in this
> Am I missing anything important?
Yes, stopping fetch ever grabbing those revisions again: history
horizons are _not_ the same thing as 'just download a bit less'. They
are intended as a 'hard stop' on history - the history behind the
horizon is forever inaccessible.
Beyond that conceptual thing, I assume you want something more like
stacking, where old content is still accessible, *if* you're online or
when you do a merge?
There, its easier, because you can allow 'merge' and other commands to
However, I would expect bugs in:
- log FILE
- fetching to old repositories (which do not support ghosts at the
store level as cleanly)
Further to that revno calculation is still all-history, and that would
really have to be fixed as a necessary condition.
I'd love to see you work on this; I suggest a long lived pipe or loom
tracking your work and all the various weird and wonderful bugs you'll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091116/77ee18e3/attachment.pgp
More information about the bazaar