[BUG] Pull command on Windows: we have 2 problems

[Robert Collins]

On Thu, 2005-10-27 at 10:48 -0500, John A Meinel wrote:

> The alternative is what we have now. Which is if you have one branch
> with a write (or read) lock, and a second branch object is created, and
> attempts to lock, you block.
> This was what was happening in the "bzr pull" code, because somewhere it
> looked back at the path, and created a new Branch object.
> 
> We can try and track down all of those places.

Which is, I think, quite easy, if our apis are all *either*:
convenience functions for top level UI's: such as 'merge' is today.

OR

deeper functions that take existing objects, i.e. they take a Branch or
a WorkingTree object, not a path on disk.

AND

The deeper layer functions do not ever create such objects.

I.e. 'pull(from_url, to_url)' constructs branches for from and to, and
then calls 'to_branch.pull(from_branch)'. (In the working-tree-less
variation of pull).

> As far as your above case, the lock would be maintained in a write-lock
> state, because it would never have been completely dropped.

If locks were shared between branches, yes. Which I think is confusing
and problematic.


Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051027/368ba79b/attachment.pgp