[MERGE][RFC] switch for heavyweight checkouts

John Arbash Meinel john at arbash-meinel.com
Fri Dec 7 17:56:13 GMT 2007


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

Ian Clatworthy wrote:
> John Arbash Meinel wrote:
...

>> ^- I would tend to not pass the url, and just have the helper use
>> "b.get_master_branch()" instead.
> 
> Done.
> 
>> Also, should we be passing around possible transports?
> 
> Done. I've submitted the tweaks to pqm but I'd appreciate it if you
> could double-check what I did here. I think my changes are safe but
> perhaps I missed some API calls which would benefit from this.

I'll peak at it at least.

The only thing I see is that Branch.get_master_branch() does not consider
itself as a 'possible_transport'. It could use self.bzrdir.transport. That
doesn't have much to do with your code, though. Just something that we need to
consider. Then again, our chances of switching when Branch is not local...
things get difficult.


> 
>> +            remote_graph = other_branch.repository.get_revision_graph(
>> +                other_last_rev)
>> +            if last_rev not in remote_graph:
>> +                return True
>>
>> ^- Using get_revision_graph() is slow. You should instead do:
>>
>> graph = this_branch.repository.get_graph(other_branch.repository)
>> if graph.is_ancestor(last_rev, other_last_rev):
>>   return True
>>
>> This can look at just the tip of the graph. And using "this.get_graph(other)"
>> will allow us to use a StackedParentsProvider that allows us to pull revisions
>> we have from the local side, rather than downloading all of the revision graph
>> from the remote side.
> 
> Sweet. FWIW, I copied that code from bind() in branch.py. :-( It's a
> little more complex but perhaps it could benefit in much the same way?
> 
> Ian C.

Actually, I might not have opened up a bug for it, but Robert and I discussed
'bzr bind' behavior. And we decided that it should not be checking the
ancestry. Or if it does, it shouldn't be failing.

The fact that it does is because it *used* to actually sync your branches at
"bind" time. So it would push your changes to the master if you were newer, or
pull the master to you if it was newer. And thus it didn't know what to do if
the branches had diverged.

Since we got rid of that behavior, we really should get rid of that check.
Because otherwise you can't do:

Oh, I really meant for these to be part of that branch...

bzr bind $OTHER
bzr update
bzr commit -m "merging in my local changes"

You can do:

bzr merge $OTHER
bzr commit -m "merging $OTHER"
bzr push $OTHER
bzr bind $OTHER

But that really is different (it changes the mainline history as part of that
push).

The alternative is having to perform gymnastics to get your branch updated to
the tip of $OTHER, and merging in the changes.

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

iD8DBQFHWYk9JdeBCYSNAAMRAukdAKCciz8NW+IJg0ibiBCl3t1uVU+ZsACgzjeR
3ay4/aZ5mMCye0hNc5IHMvA=
=U7Tn
-----END PGP SIGNATURE-----



More information about the bazaar mailing list