RFC: Initial branch operation order

Robert Collins robertc at robertcollins.net
Wed Apr 27 07:54:11 UTC 2011


On Wed, Apr 27, 2011 at 7:20 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> At the moment, our code is a bit cluttered with fetch-like operations,
> leading to bugs like:
>  https://bugs.launchpad.net/bzr/+bug/771255
>
> (initial branch doesn't copy tags)
>
> I'm thinking about improving that a bit, but my idea goes against an old
> design from Robert, that I'd like to talk through a bit.
>
> Specifically, BzrDir.sprout() re-implements a lot of Branch.pull (except
> now it doesn't have the tag-fetching code). At least a partial reason is
> because Robert didn't want us to create a proper Branch at the target
> until we had the revisions for it already copied into its Repository. So
> people wouldn't see a new Branch that had no revisions (tip ==
> 'null:'),they would just see NoSuchBranch until the fetch finished.
>
> The biggest reason for the change is that I think it would simplify the
> model (you would always use InterBranch.get() for exchanging the
> revisions, etc.)
>
> Thoughts?

Its  bit hazy now but I think I was essential overoptimising; writing
the branch tip twice is inefficient etc - but we now have a smart
server which can make the branch and repo in one call, so we wouldn't
save any latency there.

Its probably possible to make the code simpler by using a null object
or something, but I have no passionate attachment to the object
creation order (with one caveat, we shouldn't show bogus objects like
a branch with the tip not being in the repository at any point in
time).

-Rob



More information about the bazaar mailing list